From mext-bounces@ietf.org Thu May 1 07:11:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A9B53A6D0A; Thu, 1 May 2008 07:11:04 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 806133A6CE9 for ; Thu, 1 May 2008 07:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.347 X-Spam-Level: X-Spam-Status: No, score=-6.347 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1q1syt8MqEeE for ; Thu, 1 May 2008 07:11:01 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id EA5413A6861 for ; Thu, 1 May 2008 07:11:00 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.ca.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m41EArS09054; Thu, 1 May 2008 14:10:54 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 1 May 2008 09:10:42 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-00.txt Thread-index: AcirQdmn0aOVNx2vRcO71A2rFdn7yAAAy3VQ References: <4818BEE2.50806@hp.com> From: "Ahmad Muhanna" To: "Sri Gundavelli" Cc: mext Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > > > > On Wed, 30 Apr 2008, Ahmad Muhanna wrote: > > > > > I believe this is the way to have a common solution in > order to reduce > > any possible conflict. I understand that some people fear > that if that > > kind of proposal adopted some work item merely become an > IANA number > > assignment. But, IMO, that is absolutely not true. > > > > If that some people includes me, I will just say this. > > I care the least if revocation uses a new MH Type or the > sub-type from Generic Message. Forget about the fear part. [Ahmad] My bad choice of word. Meant to say "think". > However, couple of comments: > > - Revocation message is *just* another notification message. > It does not require semantics beyond a simple request/reply > message format. It is not a protocol by itself. The value > of the spec is in the use-cases and receiver action specifications. [Ahmad] If this is the scope of Notification message, then almost every protocol is nothing but a notification message, which , in general, may be true. For example: MIPv6 BU message is nothing but a notification message from the MN to the HA expressing its intent to register a care-of address. Consequently, the HA send a BA to acknowledge the notification, and so on ... However, the differentiator here is the scope of the Generic Notification Message that was presented in Prague IETF meeting and documented in the meeting minutes. Which was "an opaque string of information" Having that scope in mind, then Binding Revocation for IPv6 Mobility does not fit within this scope. It much more. > > - If there is a Notification message that is defined with the > generic event properties in mind, we dont want to replicate > that for every event. Let that generic behavior be specified > in one place, including the security semantics. Keeping the > messages to few MH types, will allow to define one set of > selectors and even allow firewall admins to properly apply the > required filters. [Ahmad] I do not think anyone disagree with this. The devil in the details. For example, looking at the latest Generic Notification Message draft, I see the following related to the processing of Generic Notification Messages: <<<<<<========>>>>>>> 5. Sending Generic Notification Messages When sending a Generic Notification message, the sending node constructs the packet as it would any other Mobility Header, except: o The MH Type field MUST be set to (TBD). The Generic Notification Request message MUST use the home agent to mobile node IPsec ESP authentication SA for integrity protection. 6. Receiving Generic Notification Messages Upon receiving a Generic Notification message, the Mobility Header MUST be verified as specified in [RFC3775], specifically: o The Checksum, MH type, Payload Proto and Header Len fields MUST meet the requirements of Section 9.2 of [RFC3775]. o The packet MUST be covered by the home agent to mobile node IPsec ESP authentication SA for integrity protection. If the packet is dropped due to the above tests, the receiving node MUST follow the processing rules as Section 9.2 of [RFC3775]. For example, it MUST send a Binding Error message with the Status field set to 2 (unrecognized MH Type value) if it does not support the message type. o If the Generic Notification message is valid according to the tests above, then it is processed according to the rules specific to the Sub-Type specified in the header. <<<<<<========>>>>>>> I may be missing something, but can some one tells me what is new in here? My point is: the common thing here is the interest to protect the MH type field by introducing a Generic MH Subtype field which can be used to define different messages with different processes. As I said before. The processing of the Generic MH Subtype message in nothing but the processing of a MH. On the other hand, one of the subtypes value of that Generic MH Subtype is reserved for a Generic Notification Message defined in the Generic Notification Message draft, another 2 values reserved for BRI and BRA which can be defined in Binding Revocation draft. What is the problem in this proposal and why there is some resistance not to accept that? > > - At the end of the day, revocation message needs a message format. > It does not diminish or increase the revocation draft value, if > it uses its own MH type or a sub-type from Notification message. [Ahmad] At the end of the day, we need to come to a framework and a proposal that works and generic enough to avoid conflict and at the same time can be expanded if necessary. Let me try this proposal and see if that make sense: 1. define a Frame Work for Generic MH Subtype message. In order to avoid conflict and have a clear mechanism for other defined messages to reference this work, it could be addressed in a couple of pages draft. 2. Generic Notification message draft reserve as many as needed subtypes and define their messages and appropriate mechanism. e.g. sending a notification message that not necessarily require reply and can be formatted as an opaque string of information, etc. 3. Binding Revocation reference the Frame work draft and reserve two subtypes for BRI and BRA and define the respected mechanism. Could we live with such proposal? > > Bottom line, Bryan or myself, care the least, if this uses a > sub-type from Notification draft or not. Do want you think is > right, if the WG and the chairs have no issue. I will leave > this thread with this note. [Ahmad] Hi Sri, I respect this! Hopefully we can use this approach after we thoroughly discuss the issue to give the chairs enough material to make a decision. Cheers! > > Thanks > Sri > > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 1 08:16:06 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 093673A6BC1; Thu, 1 May 2008 08:16:06 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0D4F3A6A7A for ; Thu, 1 May 2008 08:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goe3bv03OTkF for ; Thu, 1 May 2008 08:15:59 -0700 (PDT) Received: from web84308.mail.re1.yahoo.com (web84308.mail.re1.yahoo.com [69.147.74.187]) by core3.amsl.com (Postfix) with SMTP id 33A3728C37A for ; Thu, 1 May 2008 08:15:58 -0700 (PDT) Received: (qmail 1723 invoked by uid 60001); 1 May 2008 15:15:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=qyP0uTZRV47RRBDUFrc/OqD6eh3CCz/Hq1Edj1o1B4yvgeXLjXPkJIPCIOMbu83lFEZbi3voguSc0NUy+nt984S6opskxv8nzgpnGHQofcpqaKOcixxIvTupwYSYWeK/R5dXOUqC0QtvpoCIDev4cJILdkBQJpfkeZsQ8pUsO9E=; X-YMail-OSG: FlAJbAYVM1nmn8mzlupuIBCpA7_GBajpTqg5zXg_PNIhfxsQ4u7qFyRmbh31Fu1dQLD78fSS0hHbaM_UFOgcW4DhIn34hfS29Jl1Bf9PKB11iaTSt9MfBdrUTjI- Received: from [206.16.17.212] by web84308.mail.re1.yahoo.com via HTTP; Thu, 01 May 2008 08:15:59 PDT X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.185 Date: Thu, 1 May 2008 08:15:59 -0700 (PDT) From: Behcet Sarikaya To: Brian Haley MIME-Version: 1.0 Message-ID: <935462.1663.qm@web84308.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1300083025==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1300083025== Content-Type: multipart/alternative; boundary="0-2057853489-1209654959=:1663" --0-2057853489-1209654959=:1663 Content-Type: text/plain; charset=us-ascii Hi Brian, I agree that generic notifications can support binding revocation. My concern is that there is no use case clearly defined in the generic notifications draft. As such it is too "generic". On the other hand binding revocation is more clearly defined, in fact it is (should be) part of BU/BA exchange semantics. For example, can you say that generic notifications can be used for handover? Regards, Behcet ----- Original Message ---- From: Brian Haley To: Vijay Devarapallli Cc: mext Sent: Wednesday, April 30, 2008 1:48:02 PM Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-00.txt Hi Vijay, I've been talking with Ahmad and Sri about this off-line and we're trying to come to an agreement over some of the text in gen-notification to more easily support the revocation draft. Hopefully an update will be agreeable to everyone, but I wouldn't necessarily hold-up the current revocation draft for it. That's my thoughts at least. -Brian Vijay Devarapallli wrote: > Hi Ahmad and others, > > We previously had a discussion on this draft on the MIP6 mailing list > and it was agreed that the binding revocation message will be a > sub-type in the Generic Notification Message. > http://www.ietf.org/internet-drafts/draft-haley-mext-generic-notification-message-00.txt > > We would need to modify the generic notification message to include a > new 'subtype' field. We had discussed this in the past and made no > progress. We can start with the following values > > 0 - Reserved, not used > 1 - Notification message indicated by Mobility Options > 2 - Binding Revocation Indication > 3 - Binding Revocation Acknowledgement > 4-255 reserved > > The Generic Notification message draft is quite simple and shouldn't > take too long to standardize. It would be a good idea to use the > Generic Notification message as much as > possible when you have something to notify to either the mobile node > or the home agent. Otherwise we might end up with a proliferation of > notification messages using up a lot of mobility header message types. > > Vijay > > On Tue, Apr 29, 2008 at 6:32 PM, Ahmad Muhanna wrote: >> Hello All, >> >> Please find the latest Binding Revocation for IPv6 Mobility draft at the >> below link. >> We highly value your review and comments! >> >> Many Thanks in advance! >> >> Best Regards, >> Ahmad >> >> >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org >> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >> Internet-Drafts@ietf.org >> Sent: Tuesday, April 29, 2008 8:30 PM >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-muhanna-mext-binding-revocation-00.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Binding Revocation for IPv6 Mobility >> Author(s) : A. Muhanna, et al. >> Filename : draft-muhanna-mext-binding-revocation-00.txt >> Pages : 32 >> Date : 2008-04-29 >> >> This document defines the revocation semantics for terminating a mobile >> node's mobility session and associated resources. These semantics are >> generic enough and can be used by mobility entities in the case of >> Client Mobile IPv6 and its extensions. This mechanism allows the >> mobility entity which initiates the revocation procedure to request its >> corresponding one to terminate either one, multiple or all specified >> binding cache entries. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocatio >> n-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --0-2057853489-1209654959=:1663 Content-Type: text/html; charset=us-ascii
Hi Brian,
  I agree that generic notifications can support binding revocation. My concern is that there is no use case clearly defined in the generic notifications draft. As such it is too "generic". On the other hand binding revocation is more clearly defined, in fact it is (should be) part of BU/BA exchange semantics.
  For example, can you say that generic notifications can be used for handover?
  Regards,

Behcet
----- Original Message ----
From: Brian Haley <brian.haley@hp.com>
To: Vijay Devarapallli <dvijay@gmail.com>
Cc: mext <mext@ietf.org>
Sent: Wednesday, April 30, 2008 1:48:02 PM
Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-00.txt

Hi Vijay,

I've been talking with Ahmad and Sri about this off-line and we're
trying to come to an agreement over some of the text in gen-notification
to more easily support the revocation draft.  Hopefully an update will
be agreeable to everyone, but I wouldn't necessarily hold-up the current
revocation draft for it.  That's my thoughts at least.

-Brian

Vijay Devarapallli wrote:
> Hi Ahmad and others,
>
> We previously had a discussion on this draft on the MIP6 mailing list
> and it was agreed that the binding revocation message will be a
> sub-type in the Generic Notification Message.
> http://www.ietf.org/internet-drafts/draft-haley-mext-generic-notification-message-00.txt
>
> We would need to modify the generic notification message to include a
> new 'subtype' field. We had discussed this in the past and made no
> progress. We can start with the following values
>
> 0 - Reserved, not used
> 1 - Notification message indicated by Mobility Options
> 2 - Binding Revocation Indication
> 3 - Binding Revocation Acknowledgement
> 4-255 reserved
>
> The Generic Notification message draft is quite simple and shouldn't
> take too long to standardize. It would be a good idea to use the
> Generic Notification message as much as
> possible when you have something to notify to either the mobile node
> or the home agent. Otherwise we might end up with a proliferation of
> notification messages using up a lot of mobility header message types.
>
> Vijay
>
> On Tue, Apr 29, 2008 at 6:32 PM, Ahmad Muhanna <amuhanna@nortel.com> wrote:
>> Hello All,
>>
>>  Please find the latest Binding Revocation for IPv6 Mobility draft at the
>>  below link.
>>  We highly value your review and comments!
>>
>>  Many Thanks in advance!
>>
>>  Best Regards,
>>  Ahmad
>>
>>
>>  -----Original Message-----
>>  From: i-d-announce-bounces@ietf.org
>>  [mailto:i-d-announce-bounces@ietf.org] On Behalf Of
>>  Internet-Drafts@ietf.org
>>  Sent: Tuesday, April 29, 2008 8:30 PM
>>  To: i-d-announce@ietf.org
>>  Subject: I-D Action:draft-muhanna-mext-binding-revocation-00.txt
>>
>>  A New Internet-Draft is available from the on-line Internet-Drafts
>>  directories.
>>
>>        Title          : Binding Revocation for IPv6 Mobility
>>        Author(s)      : A. Muhanna, et al.
>>        Filename        : draft-muhanna-mext-binding-revocation-00.txt
>>        Pages          : 32
>>        Date            : 2008-04-29
>>
>>  This document defines the revocation semantics for terminating a mobile
>>  node's mobility session and associated resources.  These semantics are
>>  generic enough and can be used by mobility entities in the case of
>>  Client Mobile IPv6 and its extensions.  This mechanism allows the
>>  mobility entity which initiates the revocation procedure to request its
>>  corresponding one to terminate either one, multiple or all specified
>>  binding cache entries.
>>
>>  A URL for this Internet-Draft is:
>>  http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocatio
>>  n-00.txt
>>
>>  Internet-Drafts are also available by anonymous FTP at:
>>  ftp://ftp.ietf.org/internet-drafts/
>>
>>  Below is the data which will enable a MIME compliant mail reader
>>  implementation to automatically retrieve the ASCII version of the
>>  Internet-Draft.
>>
>> _______________________________________________
>>  MEXT mailing list
>>  MEXT@ietf.org
>>  https://www.ietf.org/mailman/listinfo/mext
>>
>>
>
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext

--0-2057853489-1209654959=:1663-- --===============1300083025== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1300083025==-- From mext-bounces@ietf.org Thu May 1 11:15:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B5623A6B70; Thu, 1 May 2008 11:15:04 -0700 (PDT) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BCA813A68CC; Thu, 1 May 2008 11:15:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080501181501.BCA813A68CC@core3.amsl.com> Date: Thu, 1 May 2008 11:15:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D ACTION:draft-ietf-mext-nemo-v4traversal-02.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6) Author(s) : H. Soliman Filename : draft-ietf-mext-nemo-v4traversal-02.txt Pages : 48 Date : 2008-5-1 The current Mobile IPv6 and NEMO specifications support IPv6 only. This specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the home agent. This specification also allows the Mobile Node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path between the mobile node and its home agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-v4traversal-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-mext-nemo-v4traversal-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-5-1111436.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Fri May 2 08:05:38 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4F0628C24F; Fri, 2 May 2008 08:05:38 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F34C53A6DD3 for ; Fri, 2 May 2008 08:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wji42KAXsZ1L for ; Fri, 2 May 2008 08:05:35 -0700 (PDT) Received: from g5t0006.atlanta.hp.com (g5t0006.atlanta.hp.com [15.192.0.43]) by core3.amsl.com (Postfix) with ESMTP id 6A45B3A6B8F for ; Fri, 2 May 2008 08:05:35 -0700 (PDT) Received: from smtp1.fc.hp.com (smtp1.fc.hp.com [15.15.136.127]) by g5t0006.atlanta.hp.com (Postfix) with ESMTP id 404BCC0C8; Fri, 2 May 2008 15:05:36 +0000 (UTC) Received: from wrx.zko.hp.com (wrx.zko.hp.com [16.116.96.52]) by smtp1.fc.hp.com (Postfix) with ESMTP id 1B1121E65A3; Fri, 2 May 2008 15:02:09 +0000 (UTC) Message-ID: <481B2DBE.5020606@hp.com> Date: Fri, 02 May 2008 11:05:34 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: Behcet Sarikaya References: <935462.1663.qm@web84308.mail.re1.yahoo.com> In-Reply-To: <935462.1663.qm@web84308.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Behcet, Behcet Sarikaya wrote: > Hi Brian, > I agree that generic notifications can support binding revocation. My > concern is that there is no use case clearly defined in the generic > notifications draft. As such it is too "generic". On the other hand > binding revocation is more clearly defined, in fact it is (should be) > part of BU/BA exchange semantics. I'll let WG consensus decide if revocation should define two new MH types or use gen-notification. > For example, can you say that generic notifications can be used for > handover? Well, if I wrote the Generic Notification draft first, HA Switch could have maybe just been a mobility option. -Brian > ----- Original Message ---- > From: Brian Haley > To: Vijay Devarapallli > Cc: mext > Sent: Wednesday, April 30, 2008 1:48:02 PM > Subject: Re: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-00.txt > > Hi Vijay, > > I've been talking with Ahmad and Sri about this off-line and we're > trying to come to an agreement over some of the text in gen-notification > to more easily support the revocation draft. Hopefully an update will > be agreeable to everyone, but I wouldn't necessarily hold-up the current > revocation draft for it. That's my thoughts at least. > > -Brian > > Vijay Devarapallli wrote: > > Hi Ahmad and others, > > > > We previously had a discussion on this draft on the MIP6 mailing list > > and it was agreed that the binding revocation message will be a > > sub-type in the Generic Notification Message. > > > http://www.ietf.org/internet-drafts/draft-haley-mext-generic-notification-message-00.txt > > > > We would need to modify the generic notification message to include a > > new 'subtype' field. We had discussed this in the past and made no > > progress. We can start with the following values > > > > 0 - Reserved, not used > > 1 - Notification message indicated by Mobility Options > > 2 - Binding Revocation Indication > > 3 - Binding Revocation Acknowledgement > > 4-255 reserved > > > > The Generic Notification message draft is quite simple and shouldn't > > take too long to standardize. It would be a good idea to use the > > Generic Notification message as much as > > possible when you have something to notify to either the mobile node > > or the home agent. Otherwise we might end up with a proliferation of > > notification messages using up a lot of mobility header message types. > > > > Vijay > > > > On Tue, Apr 29, 2008 at 6:32 PM, Ahmad Muhanna > wrote: > >> Hello All, > >> > >> Please find the latest Binding Revocation for IPv6 Mobility draft > at the > >> below link. > >> We highly value your review and comments! > >> > >> Many Thanks in advance! > >> > >> Best Regards, > >> Ahmad > >> > >> > >> -----Original Message----- > >> From: i-d-announce-bounces@ietf.org > > >> [mailto:i-d-announce-bounces@ietf.org > ] On Behalf Of > >> Internet-Drafts@ietf.org > >> Sent: Tuesday, April 29, 2008 8:30 PM > >> To: i-d-announce@ietf.org > >> Subject: I-D Action:draft-muhanna-mext-binding-revocation-00.txt > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> > >> Title : Binding Revocation for IPv6 Mobility > >> Author(s) : A. Muhanna, et al. > >> Filename : draft-muhanna-mext-binding-revocation-00.txt > >> Pages : 32 > >> Date : 2008-04-29 > >> > >> This document defines the revocation semantics for terminating a mobile > >> node's mobility session and associated resources. These semantics are > >> generic enough and can be used by mobility entities in the case of > >> Client Mobile IPv6 and its extensions. This mechanism allows the > >> mobility entity which initiates the revocation procedure to request its > >> corresponding one to terminate either one, multiple or all specified > >> binding cache entries. > >> > >> A URL for this Internet-Draft is: > >> > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocatio > >> n-00.txt > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> Below is the data which will enable a MIME compliant mail reader > >> implementation to automatically retrieve the ASCII version of the > >> Internet-Draft. > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > >> > >> > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri May 2 10:38:30 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 016043A6ACD; Fri, 2 May 2008 10:38:30 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A2433A6CFB for ; Fri, 2 May 2008 10:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GX6zALgWM+oR for ; Fri, 2 May 2008 10:38:28 -0700 (PDT) Received: from zrtps0kp.us.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 9B0533A6ACD for ; Fri, 2 May 2008 10:38:24 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m42HcNx15380 for ; Fri, 2 May 2008 17:38:23 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 2 May 2008 12:37:53 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-00.txt Thread-index: AcirQdmn0aOVNx2vRcO71A2rFdn7yAAAy3VQABTMvBAANuRWIAABsPTw From: "Mohamed Khalil" To: "mext" Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi All, > > > > > - At the end of the day, revocation message needs a message format. > > It does not diminish or increase the revocation draft value, if > > it uses its own MH type or a sub-type from Notification message. > > [Ahmad] > At the end of the day, we need to come to a framework and a proposal > that works and generic enough to avoid conflict and at the same time > can be expanded if necessary. > > Let me try this proposal and see if that make sense: > > 1. define a Frame Work for Generic MH Subtype message. In order to > avoid conflict and have a clear mechanism for other defined messages > to reference this work, it could be addressed in a couple of pages > draft. > > 2. Generic Notification message draft reserve as many as needed > subtypes and define their messages and appropriate mechanism. e.g. > sending a notification message that not necessarily require reply and > can be formatted as an opaque string of information, etc. > > 3. Binding Revocation reference the Frame work draft and reserve two > subtypes for BRI and BRA and define the respected mechanism. > > Could we live with such proposal? > [MK] I think we have put more time than necessary discussing this issue. There has been an agreement before that the semantics for Binding Revocation is absolutely different than "Send it and forget about it" Notification message and that was the reason for coming with the subtype proposal. As was pointed out earlier by many people on this list before, there is a 3GPP dependency on the Binding Revocation and we need to move this forward. I support this proposal, and let us go forward! Cheers! ==================================================This is the END================================= _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri May 2 14:01:57 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B0C128C11D; Fri, 2 May 2008 14:01:57 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDBE23A6A80 for ; Fri, 2 May 2008 14:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.369 X-Spam-Level: X-Spam-Status: No, score=-6.369 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktno3DFz4K0u for ; Fri, 2 May 2008 14:01:54 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 321BC3A6ADA for ; Fri, 2 May 2008 14:01:54 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m42L0p102903; Fri, 2 May 2008 21:00:51 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 2 May 2008 16:01:42 -0500 Message-ID: In-Reply-To: <935462.1663.qm@web84308.mail.re1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-00.txt Thread-index: AcirnmdTwTkrl4i8S9etIRK8HkmCZwA8Y1uA References: <935462.1663.qm@web84308.mail.re1.yahoo.com> From: "Ahmad Muhanna" To: "Behcet Sarikaya" , "Brian Haley" Cc: mext@ietf.org Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0526954823==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============0526954823== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8AC97.B9DA5551" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8AC97.B9DA5551 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Behcet,=20 =20 Thanks for your comments.=20 Please see my comments inline. Regards,=20 Ahmad ________________________________ From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Behcet Sarikaya Sent: Thursday, May 01, 2008 10:16 AM To: Brian Haley Cc: mext@ietf.org Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-00.txt =09 =09 Hi Brian, I agree that generic notifications can support binding revocation. =20 [Ahmad] =20 Actually as you may remember, we spent a lot of time discussing this few months back and the conclusion was that the semantic of Binding Revocation is totally different than the Generic Notification Message "Send it and forget about it, to borrow a line from MK posting:)=20 Actually, that why I personally proposed a compromise to kill two birds in one stone:=20 =20 =09 1. Provide a mechanism to preserve the MH Type field by Introducing a new Generic MH Subtype field to be used to define Generic Mobility Header Subtype messages, e.g. Revocation messages, Generic notification message, etc. =20 2. Provide a Generic framework to allow the introduction of messages with different semantics and mechanism to co-exist, e.g., BRI/BRA and Generic Notification Message. =20 My concern is that there is no use case clearly defined in the generic notifications draft. As such it is too "generic". =20 On the other hand binding revocation is more clearly defined, =20 [Ahmad] Thanks! =20 in fact it is (should be) part of BU/BA exchange semantics. For example, can you say that generic notifications can be used for handover?=20 Regards, =09 Behcet =09 ----- Original Message ---- From: Brian Haley To: Vijay Devarapallli Cc: mext Sent: Wednesday, April 30, 2008 1:48:02 PM Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-00.txt =09 Hi Vijay, =09 I've been talking with Ahmad and Sri about this off-line and we're=20 trying to come to an agreement over some of the text in gen-notification=20 to more easily support the revocation draft. Hopefully an update will=20 be agreeable to everyone, but I wouldn't necessarily hold-up the current=20 revocation draft for it. That's my thoughts at least. =09 -Brian =09 Vijay Devarapallli wrote: > Hi Ahmad and others, >=20 > We previously had a discussion on this draft on the MIP6 mailing list > and it was agreed that the binding revocation message will be a > sub-type in the Generic Notification Message. > http://www.ietf.org/internet-drafts/draft-haley-mext-generic-notificatio n-message-00.txt >=20 > We would need to modify the generic notification message to include a > new 'subtype' field. We had discussed this in the past and made no > progress. We can start with the following values >=20 > 0 - Reserved, not used > 1 - Notification message indicated by Mobility Options > 2 - Binding Revocation Indication > 3 - Binding Revocation Acknowledgement > 4-255 reserved >=20 > The Generic Notification message draft is quite simple and shouldn't > take too long to standardize. It would be a good idea to use the > Generic Notification message as much as > possible when you have something to notify to either the mobile node > or the home agent. Otherwise we might end up with a proliferation of > notification messages using up a lot of mobility header message types. >=20 > Vijay >=20 > On Tue, Apr 29, 2008 at 6:32 PM, Ahmad Muhanna wrote: >> Hello All, >> >> Please find the latest Binding Revocation for IPv6 Mobility draft at the >> below link. >> We highly value your review and comments! >> >> Many Thanks in advance! >> >> Best Regards, >> Ahmad >> >> >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org >> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >> Internet-Drafts@ietf.org >> Sent: Tuesday, April 29, 2008 8:30 PM >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-muhanna-mext-binding-revocation-00.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Binding Revocation for IPv6 Mobility >> Author(s) : A. Muhanna, et al. >> Filename : draft-muhanna-mext-binding-revocation-00.txt >> Pages : 32 >> Date : 2008-04-29 >> >> This document defines the revocation semantics for terminating a mobile >> node's mobility session and associated resources. These semantics are >> generic enough and can be used by mobility entities in the case of >> Client Mobile IPv6 and its extensions. This mechanism allows the >> mobility entity which initiates the revocation procedure to request its >> corresponding one to terminate either one, multiple or all specified >> binding cache entries. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocatio >> n-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext =09 ------_=_NextPart_001_01C8AC97.B9DA5551 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi=20 Behcet,
 
Thanks=20 for your comments.
Please=20 see my comments inline.

Regards, =
Ahmad

From: mext-bounces@ietf.org=20 [mailto:mext-bounces@ietf.org] On Behalf Of Behcet=20 Sarikaya
Sent: Thursday, May 01, 2008 10:16 AM
To: = Brian=20 Haley
Cc: mext@ietf.org
Subject: Re: [MEXT] FW: = I-D=20 = Action:draft-muhanna-mext-binding-revocation-00.txt

Hi=20 Brian,
  I agree that generic notifications can support = binding=20 revocation.   [Ahmad]   Actually as you=20 may remember, we spent a lot of time discussing this few months back = and the=20 conclusion was that the semantic of Binding Revocation is totally = different=20 than the Generic Notification Message "Send it and = forget about=20 it, to borrow a line from MK posting:) = Actually, that=20 why I personally proposed a compromise to kill two birds in = one=20 stone:   1. Provide a=20 mechanism to preserve the MH Type field by Introducing a=20 new Generic MH Subtype field to be used to define Generic = Mobility Header=20 Subtype messages, e.g. Revocation messages, Generic notification = message,=20 etc.   2. Provide a Generic framework to allow the = introduction of messages with different semantics and mechanism = to=20 co-exist, e.g., BRI/BRA and Generic Notification=20 Message.    My concern is that there is no = use case=20 clearly defined in the generic notifications draft. As such it is too=20 "generic".    On the other hand binding = revocation is=20 more clearly defined,   [Ahmad] Thanks!     in fact it is (should be) = part of BU/BA=20 exchange semantics.
  For example, can you say that generic=20 notifications can be used for handover?
 =20 Regards,

Behcet
-----=20 Original Message ----
From: Brian Haley = <brian.haley@hp.com>
To:=20 Vijay Devarapallli <dvijay@gmail.com>
Cc: mext=20 <mext@ietf.org>
Sent: Wednesday, April 30, 2008 1:48:02=20 PM
Subject: Re: [MEXT] FW: I-D=20 Action:draft-muhanna-mext-binding-revocation-00.txt

Hi=20 Vijay,

I've been talking with Ahmad and Sri about this off-line = and=20 we're
trying to come to an agreement over some of the text in=20 gen-notification
to more easily support the revocation = draft. =20 Hopefully an update will
be agreeable to everyone, but I wouldn't=20 necessarily hold-up the current
revocation draft for it.  = That's my=20 thoughts at least.

-Brian

Vijay Devarapallli = wrote:
> Hi=20 Ahmad and others,
>
> We previously had a discussion on = this=20 draft on the MIP6 mailing list
> and it was agreed that the = binding=20 revocation message will be a
> sub-type in the Generic = Notification=20 Message.
> http://www.ietf.org/internet-drafts/draft-haley-mext-gene= ric-notification-message-00.txt
>=20
> We would need to modify the generic notification message to = include=20 a
> new 'subtype' field. We had discussed this in the past and = made=20 no
> progress. We can start with the following values
> =
> 0=20 - Reserved, not used
> 1 - Notification message indicated by = Mobility=20 Options
> 2 - Binding Revocation Indication
> 3 - Binding=20 Revocation Acknowledgement
> 4-255 reserved
>
> The = Generic=20 Notification message draft is quite simple and shouldn't
> take = too long=20 to standardize. It would be a good idea to use the
> Generic=20 Notification message as much as
> possible when you have = something to=20 notify to either the mobile node
> or the home agent. Otherwise = we might=20 end up with a proliferation of
> notification messages using up = a lot of=20 mobility header message types.
>
> Vijay
>
> = On Tue,=20 Apr 29, 2008 at 6:32 PM, Ahmad Muhanna <amuhanna@nortel.com>=20 wrote:
>> Hello All,
>>
>>  Please = find the=20 latest Binding Revocation for IPv6 Mobility draft at = the
>> =20 below link.
>>  We highly value your review and=20 comments!
>>
>>  Many Thanks in=20 advance!
>>
>>  Best Regards,
>>  = Ahmad
>>
>>
>>  -----Original=20 Message-----
>>  From: i-d-announce-bounces@iet= f.org
>> =20 [mailto:i-d-announce-bounces@iet= f.org]=20 On Behalf Of
>>  Internet-Drafts@ietf.org<= BR>>> =20 Sent: Tuesday, April 29, 2008 8:30 PM
>>  To: i-d-announce@ietf.org
>= ;> =20 Subject: I-D=20 = Action:draft-muhanna-mext-binding-revocation-00.txt
>>
>&g= t; =20 A New Internet-Draft is available from the on-line=20 Internet-Drafts
>>  = directories.
>>
>> =20       Title          : Binding = Revocation for IPv6 Mobility
>>       =20 Author(s)      : A. Muhanna, et al.
>>  =  =20     Filename        :=20 draft-muhanna-mext-binding-revocation-00.txt
>>    =  =20   Pages          : 32
>>  =  =20     Date            :=20 2008-04-29
>>
>>  This document defines the = revocation=20 semantics for terminating a mobile
>>  node's mobility = session=20 and associated resources.  These semantics are
>>  = generic=20 enough and can be used by mobility entities in the case = of
>> =20 Client Mobile IPv6 and its extensions.  This mechanism allows=20 the
>>  mobility entity which initiates the revocation = procedure=20 to request its
>>  corresponding one to terminate either = one,=20 multiple or all specified
>>  binding cache=20 entries.
>>
>>  A URL for this Internet-Draft=20 is:
>>  http://www.ietf.org/internet-drafts/draft-muhanna-mext-bi= nding-revocatio
>> =20 n-00.txt
>>
>>  Internet-Drafts are also = available by=20 anonymous FTP at:
>>  ftp://ftp.ietf.org/internet-drafts/
>>
&g= t;> =20 Below is the data which will enable a MIME compliant mail=20 reader
>>  implementation to automatically retrieve the = ASCII=20 version of the
>>  = Internet-Draft.
>>
>>=20 _______________________________________________
>>  MEXT = mailing=20 list
>>  MEXT@ietf.org
>>  = https://www.ietf.org/mailman/listinfo/mext
>>= ;
>>
>=20
_______________________________________________
MEXT mailing = list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext

------_=_NextPart_001_01C8AC97.B9DA5551-- --===============0526954823== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0526954823==-- From mext-bounces@ietf.org Fri May 2 14:25:24 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 120D93A6E3E; Fri, 2 May 2008 14:25:24 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E13233A6E54 for ; Fri, 2 May 2008 14:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.389 X-Spam-Level: X-Spam-Status: No, score=-6.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYH0X6tuf6kW for ; Fri, 2 May 2008 14:25:17 -0700 (PDT) Received: from zrtps0kn.us.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id CD3CF3A6EA0 for ; Fri, 2 May 2008 14:24:57 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m42LOok04469; Fri, 2 May 2008 21:24:51 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 2 May 2008 16:24:25 -0500 Message-ID: In-Reply-To: <481B2DBE.5020606@hp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-00.txt Thread-index: AcisZgajIsShiz9NSrC1XTquiR0ADwAM8ZNg References: <935462.1663.qm@web84308.mail.re1.yahoo.com> <481B2DBE.5020606@hp.com> From: "Ahmad Muhanna" To: "Brian Haley" , "Behcet Sarikaya" Cc: mext@ietf.org Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Brian, Please see comment inline. Regards, Ahmad > Action:draft-muhanna-mext-binding-revocation-00.txt > > Hi Behcet, > > Behcet Sarikaya wrote: > > Hi Brian, > > I agree that generic notifications can support binding > revocation. > > My concern is that there is no use case clearly defined in > the generic > > notifications draft. As such it is too "generic". On the other hand > > binding revocation is more clearly defined, in fact it is > (should be) > > part of BU/BA exchange semantics. > > I'll let WG consensus decide if revocation should define two > new MH types or use gen-notification. > > > For example, can you say that generic notifications can > be used for > > handover? > > Well, if I wrote the Generic Notification draft first, HA > Switch could have maybe just been a mobility option. [Ahmad] It actually depends on the scope, for example, if we go a little back in time and according to the "request/Reply" scope for the Generic Notification Message that was mentioned earlier: may be; we could have defined MIP6 BU/BA as Generic Notification Messages and closed all the books and saved ourselves a lot of time and resources. Cheers! > > -Brian > > > ----- Original Message ---- > > From: Brian Haley > > To: Vijay Devarapallli > > Cc: mext > > Sent: Wednesday, April 30, 2008 1:48:02 PM > > Subject: Re: [MEXT] FW: I-D > > Action:draft-muhanna-mext-binding-revocation-00.txt > > > > Hi Vijay, > > > > I've been talking with Ahmad and Sri about this off-line and we're > > trying to come to an agreement over some of the text in > > gen-notification to more easily support the revocation draft. > > Hopefully an update will be agreeable to everyone, but I wouldn't > > necessarily hold-up the current revocation draft for it. > That's my thoughts at least. > > > > -Brian > > > > Vijay Devarapallli wrote: > > > Hi Ahmad and others, > > > > > > We previously had a discussion on this draft on the MIP6 mailing > > list > and it was agreed that the binding revocation > message will be > > a > sub-type in the Generic Notification Message. > > > > > > http://www.ietf.org/internet-drafts/draft-haley-mext-generic-notificat > > ion-message-00.txt > > > > > > We would need to modify the generic notification message > to include > > a > new 'subtype' field. We had discussed this in the past > and made > > no > progress. We can start with the following values > > 0 - > > Reserved, not used > 1 - Notification message indicated by > Mobility > > Options > 2 - Binding Revocation Indication > 3 - Binding > Revocation > > Acknowledgement > 4-255 reserved > > The Generic Notification > > message draft is quite simple and shouldn't > take too long to > > standardize. It would be a good idea to use the > Generic > > Notification message as much as > possible when you have > something to > > notify to either the mobile node > or the home agent. Otherwise we > > might end up with a proliferation of > notification > messages using up > > a lot of mobility header message types. > > > > > > Vijay > > > > > > On Tue, Apr 29, 2008 at 6:32 PM, Ahmad Muhanna > > > wrote: > > >> Hello All, > > >> > > >> Please find the latest Binding Revocation for IPv6 > Mobility draft > > at the >> below link. > > >> We highly value your review and comments! > > >> > > >> Many Thanks in advance! > > >> > > >> Best Regards, > > >> Ahmad > > >> > > >> > > >> -----Original Message----- > > >> From: i-d-announce-bounces@ietf.org > > > > >> [mailto:i-d-announce-bounces@ietf.org > > ] On Behalf Of >> > > Internet-Drafts@ietf.org > >> Sent: > > Tuesday, April 29, 2008 8:30 PM >> To: i-d-announce@ietf.org > > >> Subject: I-D > > Action:draft-muhanna-mext-binding-revocation-00.txt > > >> > > >> A New Internet-Draft is available from the on-line > > Internet-Drafts >> directories. > > >> > > >> Title : Binding Revocation for IPv6 Mobility > > >> Author(s) : A. Muhanna, et al. > > >> Filename : > draft-muhanna-mext-binding-revocation-00.txt > > >> Pages : 32 > > >> Date : 2008-04-29 > > >> > > >> This document defines the revocation semantics for > terminating a > > mobile >> node's mobility session and associated > resources. These > > semantics are >> generic enough and can be used by > mobility entities > > in the case of >> Client Mobile IPv6 and its extensions. This > > mechanism allows the >> mobility entity which initiates the > > revocation procedure to request its >> corresponding one to > > terminate either one, multiple or all specified >> > binding cache entries. > > >> > > >> A URL for this Internet-Draft is: > > >> > > > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocat > > io > > >> n-00.txt > > >> > > >> Internet-Drafts are also available by anonymous FTP at: > > >> ftp://ftp.ietf.org/internet-drafts/ > > >> > > >> Below is the data which will enable a MIME compliant > mail reader > > >> implementation to automatically retrieve the ASCII > version of the > > >> Internet-Draft. > > >> > > >> _______________________________________________ > > >> MEXT mailing list > > >> MEXT@ietf.org >> > > https://www.ietf.org/mailman/listinfo/mext > > >> > > >> > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri May 2 15:00:02 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5B2F3A6E62; Fri, 2 May 2008 15:00:02 -0700 (PDT) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 20E1E3A6E4F; Fri, 2 May 2008 15:00:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080502220001.20E1E3A6E4F@core3.amsl.com> Date: Fri, 2 May 2008 15:00:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-aaa-ha-goals-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : AAA Goals for Mobile IPv6 Author(s) : G. Giaretta, et al. Filename : draft-ietf-mext-aaa-ha-goals-01.txt Pages : 12 Date : 2008-05-02 In commercial and enterprise deployments Mobile IPv6 can be a service offered by a Mobility Services Provider (MSP). In this case all protocol operations may need to be explicitly authorized and traced, requiring the interaction between Mobile IPv6 and the AAA infrastructure. Integrating the AAA infrastructure (e.g. NAS and AAA server) offers also a solution component for Mobile IPv6 bootstrapping. This document describes various scenarios where a AAA interface for Mobile IPv6 is required. Additionally, it lists design goals and requirements for such an interface. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-aaa-ha-goals-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-mext-aaa-ha-goals-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-02145147.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Fri May 2 20:30:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 435AF3A6D1B; Fri, 2 May 2008 20:30:04 -0700 (PDT) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E9B453A6B13; Fri, 2 May 2008 20:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080503033001.E9B453A6B13@core3.amsl.com> Date: Fri, 2 May 2008 20:30:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-monami6-multihoming-motivation-scenario-03.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Motivations and Scenarios for Using Multiple Interfaces and Global Addresses Author(s) : T. Ernst, et al. Filename : draft-ietf-monami6-multihoming-motivation-scenario-03.txt Pages : 20 Date : 2008-05-02 In this document, multihoming is investigated from an end-node point of view, and not from a site point of view as the term "multihoming" is commonly understood so far. The purpose of this document is to explain the motivations for fixed and mobile nodes (hosts and routers) using multiple interfaces and the scenarios where this may end up using multiple global addresses on their interfaces. Such multihoming configurations can bring a number of benefits once appropriate support mechanisms are put in place. Interestingly, this analysis is generic, i.e. motivations and benefits of node multihoming apply to both fixed end nodes and mobile end nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-monami6-multihoming-motivation-scenario-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-monami6-multihoming-motivation-scenario-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-02202130.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Fri May 2 20:30:05 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1CE73A6E31; Fri, 2 May 2008 20:30:05 -0700 (PDT) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F10A63A6C88; Fri, 2 May 2008 20:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080503033001.F10A63A6C88@core3.amsl.com> Date: Fri, 2 May 2008 20:30:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-monami6-mipv6-analysis-05.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Analysis of Multihoming in Mobile IPv6 Author(s) : N. Montavont, et al. Filename : draft-ietf-monami6-mipv6-analysis-05.txt Pages : 31 Date : 2008-05-02 Mobile IPv6 as specified in RFC 3775 allows a mobile node to maintain its IPv6 communications while moving between subnets. This document investigates configurations where a mobile node running Mobile IPv6 is multihomed. The use of multiple addresses is foreseen to provide ubiquitous, permanent and fault-tolerant access to the Internet, particularly on mobile nodes which are more prone to failure or sudden lack of connectivity. However, Mobile IPv6 currently lacks support for such multihomed nodes. The purpose of this document is to detail all the issues arising through the operation of Mobile IPv6 on multihomed mobile nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-monami6-mipv6-analysis-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-monami6-mipv6-analysis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-02202153.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Fri May 2 20:50:30 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0E8C3A6E64; Fri, 2 May 2008 20:50:30 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 290993A67AD for ; Fri, 2 May 2008 20:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAAD8s2-+m9F for ; Fri, 2 May 2008 20:50:27 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id B7A713A6A58 for ; Fri, 2 May 2008 20:49:20 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id m433nK4s022042 for ; Sat, 3 May 2008 12:49:20 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb3) with ESMTP id m433nKG18944 for ; Sat, 3 May 2008 12:49:20 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili06) with ESMTP id m433nKT07385 for ; Sat, 3 May 2008 12:49:20 +0900 (JST) Received: from ncc1701e.sg.panasonic.com ([10.81.113.10]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Sat, 3 May 2008 11:48:35 +0800 Received: by ncc1701e.sg.panasonic.com (Postfix, from userid 1000) id B85EF264E220; Sat, 3 May 2008 11:49:07 +0800 (SGT) From: Chan-Wah Ng To: mext In-Reply-To: <481858A0.20102@it.uc3m.es> References: <20080430013001.6B3FA3A6C64@core3.amsl.com> <481858A0.20102@it.uc3m.es> Organization: Panasonic Singapore Labs Date: Sat, 03 May 2008 11:49:07 +0800 Message-Id: <1209786547.6310.17.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 X-OriginalArrivalTime: 03 May 2008 03:48:37.0068 (UTC) FILETIME=[914878C0:01C8ACD0] Subject: Re: [MEXT] WGLC for draft-ietf-monami6-multiplecoa-07.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: chanwah.ng@sg.panasonic.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Wed, 2008-04-30 at 13:31 +0200, marcelo bagnulo braun wrote: > Hi, > > This is the WGLC for draft-ietf-monami6-multiplecoa-07.txt. Please check > if all the issues that were raised have been addressed in this new > version. If you have issues with the document, please raise them. If you > are ok with the document and you think it should be sent to the ISEG, > please also say so. Provide comments till may 14. > For your convinience, the document can be found at: > > Title : Multiple Care-of Addresses Registration > Author(s) : R. Wakikawa, et al. > Filename : draft-ietf-monami6-multiplecoa-07.txt > Pages : 44 > Date : 2008-04-29 > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-07.txt > Hello, following is my review on the first 7 sections of the draft. --- [Section 1 - Pg 5] The first paragraph explained the motivation for this work, but failed to reference the other WG document on the analysis of why MIPv6 cannot fulfill such motivation. I would add in some text as follows: A mobile node may use various types of network interfaces to obtain durable and wide area network connectivity. This is increasingly become true with mobile nodes having multiple interfaces such as 802.2, 802.11, 802.16, cellular radios, etc.. The motivations for and benefits of using multiple points of attachment are discussed in [ID-MOTIVATION]. When a mobile node with multiple interfaces uses Mobile IPv6 [RFC-3775] for mobility management, it cannot use its multiple interfaces to send and receive packets while taking advantage of session continuity provided by Mobile IPv6. This is because Mobile IPv6 allows the mobile node to only bind one care-of address at a time with its home address. See [ID-MIP6ANALYSIS] on a further analysis of using multiple interfaces and addresses with Mobile IPv6. ---- [Section 2 - Pg 6] Binding Identification number (BID) The BID ... ... Zero and negative values MUST NOT be used. This is strange ... BID is defined as unsigned 16 bit integer ... how can negative values be used? What is the meaning of "negative values" here? Note same comment applies to [Section 5.1, pg 16]. Bulk Registration A mobile node can register multiple bindings at once by sending a single Binding Update. A mobile node can also replace some or all the bindings available at the home agent with the new bindings by using the bulk registration. Bulk registration is supported only for home registration (i.e. with the home agent) as explained in Section 5.4. A mobile node MUST NOT perform bulk registration with a correspondent node. The last part seems to be too strong ... the only reason why an MN should not perform bulk registration IMHO is because this specification does not want to support it "for protocol simplicity". Simply say so like changing the last sentence to "Bulk registration with a correpondent node is not supported in this specification." Saying MN "MUST NOT" seems to suggest there is a strong security or protocol design reason for MN not to do so which is not explained -- the only reason stated is in pg 7: .... For protocol simplicity, bulk registration to correspondent nodes is not supported in this document. This is because the Return Routability mechanism introduced in [RFC-3775] cannot be easily extended to verify multiple care-of addresses stored in a single Binding Update. This, IMHO, does not justify the use of a strong "MUST NOT". --- [Section 3 - Pg 7] Editorial -- plural/singular mismatch: Figure 1 illustrates the configuration where the mobile node obtains multiple care-of addresses at foreign links. The mobile node can utilize all the care-of address. In Figure 1, the home address of ^^^^^^^ addresses --- [ Section 4.2 - Pg 12-14] 4.2. Binding Identifier Mobility Option Typically for new options defined, the byte alignment should be specified. This may get a bit tricky, though, since depending on whether Care-of Address field is present or not, and what kind of care-of address, the byte alignment requirement will change. ... Status When the Binding Identifier mobility option is included in a Binding Acknowledgement, this field overwrites the status field in the Binding Acknowledgement. If this field is zero, the receiver MUST use the registration status stored in the Binding Acknowledgement message. This Status field is also used to carry error information related to the care-of address test in the Care-of Test message. The status is 8-bit unsigned integer. The possible status codes are the same as the status codes of Binding Acknowledgement. What happens to this field when the option is included in the Binding Update message? Should it be set to zero, and ignored by the receiver or what? ... Reserved 5 bits Reserved field. The reserved field MUST be zero. Typically, a spec would mandate sender to set reserved bit to 0 and response of receiver if the bits are non-zero -- so should the receiver silently ignore the bits, silently discard the BU, reply with Binding Error, or what? --- Care-of Address This field has the variable length depending on the specified flags. Either IPv4 or IPv6 care-of address for the corresponding BID can be stored in this field. This field MUST NOT be used if a Binding Identifier mobility option is included in any other message other than a Binding Update. The description of this field leaves me wondering. Firstly, "depending on the specified flags." What flags? Whose flags? There are only two flags in this option, H and O. None seems to affect the length of this field. A more precise description should be given here. Secondly, "This field MUST NOT be used ... in any other message other than a Binding Update". What is the meaning of must not be used? Does it means that this field is still there in a BA? Should the field becomes a zero-length field in BA or should it be set to zero and ignored by receiver? Or if the field is not there, i.e. the Length field is 8, then this field can be omitted in this option (which is the case based on later sections). Some text here should describe it clearly here. Answering this question also goes back to the question of byte alignment for this BID option. --- [Section 4.3 - pg 14 to 15] MCOA NOTCOMPLETE (TBD < 128) MCOA RETURNHOME WO/NDP (TBD < 128) MCOA MALFORMED (TBD more than 128) MCOA BID CONFLICT (TBD more than 128) ... Editorial -- you used "TBD < 128" but use "TBD more than 128". Better to be consistent. --- [Section 5.3, pg 17] IPv6 header (src=CoA, dst=HA) IPv6 Home Address Option ESP Header (for home registration) Mobility header -Binding Update Mobility Options - Binding Identifier mobility option - Binding Authorization mobility option (for Route Optimization) Figure 6: Binding Update for Binding Registration Figure 6 uses parenthesis in inconsistent ways. The first line, IPv6 Header, it is used to display the contents; subsequently, it is used to indicate the conditions for the relevant contents to be there. I would instead suggest you break the figure into two, one for BU sent to HA, and one for BU sent to CN, thereby eliminating the need for subsequent parenthesis. Also, the use "-" as bullets can be omitted. --- [Section 5.5, pg 18] .... The care-of addresses field in each mobility option SHOULD be omitted by the sender and MUST be ignored by the receiver. This is because the receiver will remove the binding that matches the specified BID. Similar to previous comment in Section 4.2, what is the meaning of "should be ommitted"? The filed is there or not? --- [Section 6.1, pg 27] Apart from the first paragraph, the section seems to concentrate only on correspondent node. I think the description fits both the correspondent node and home agent. Thus, the terminology used should be corrected (either replace "correspondent node" with "correspondent node or home agent", or create a term such as "correspondent entity" as per RFC 4889, "recipient", or even "the node" as used in later part of Sect 5). --- [Section 6.3, pg 28] o When the Length value is either 12 or 20, the care-of address MUST be present in the Binding Identifier mobility option. If the care-of address is not present, the receiver MUST reject the Binding Identifier mobility option and returns the status value set to [MCOA MALFORMED]. If the Length value is 12, an IPv4 valid address MUST be present. Otherwise, an IPv6 address MUST be stored in the Binding Identifier mobility option. The description here is a bit dubious. If the length is 12 or 20, the next 32 or 128 bits after the Reserved field would be treated as the care-of address. Since this is a section about CN/HA's operation, it shouldn't be CoA "MUST be present". This is not a requirement for the recipient, it is a requirement on the sender. Instead, the CN/HA "MUST treat the next few bits after Reserved field as the CoA. Similarly, there is no such thing as "If the care-of address is not present". So, the wording should instead be "if the address in the Care-of Address is not valid". Similarly for the later part, it is not a question of IPv4/IPv6 address must be present. It should instead be phrased as that the CN/HA must treat the next 32 bits as an IPv4 care-of address, or next 128bits as an IPv6 care-of address, and then returns error if it is not a valid care-of address. --- [Section 6.3, pg 29] o If the 'O' flag is set in the de-registering Binding Update, it is ignored. If the 'H' flag is set, the home agent stores a home address in the Care-of Address field of the binding cache entry. The home agent also stops performing proxy ND for the mobile node's home address. The last part doesn't seems to be in sync with what was mentioned in Section 5.6.3. I think the home agent would decide whether to stop or continue ND proxy depending on whether it is the only router on the home link, and responds with the appropriate Status code according to Sect 5.6.3. --- [Section 6.3, pg 29] When a correspondent node sends a Binding Acknowledgement, the status value MUST be always stored in the Status field of the Binding Acknowledgement and the Status field of Binding Identifier mobility option set to zero. For the home agent, the status value can be stored in the Status field of either a Binding Acknowledgement or a Binding Identifier mobility option. If the status value is specific to one of bindings in the bulk registration, the status value MUST be stored in the Status field in the corresponding Binding Identifier mobility option. In this case, [MCOA NOTCOMPLETE] MUST be set to the Status field of the Binding Acknowledgement so that the receiver can examine the Status field of each Binding Identifier mobility option for further operations. In the later part on home agent of the above paragraph, I think it might be necessary to say that for BID Options that do not have a specific different status, the status field of these BID options should be set to zero (which mean the status in the BA will be used). --- [Section 6.4, Pg 30] 6.4. Sending Binding Refresh Request When a node (home agent or correspondent node) sends a Binding Refresh Request for a particular binding created with the BID, the node SHOULD include the Binding Identifier mobility option in the Binding Refresh Request. If the mobile node had used bulk registration, the sender SHOULD include all the Binding Identifier mobility options. If the mobile node had not used bulk registration, the sender includes the Binding Identifier mobility options only for those bindings that need to be refreshed. The second sentence seems to indicate that the home agent must somehow recall if the mobile node had previously used Bulk Registration or not. No where else in this spec seems to mention this requirement for the home agent. My personal feeling is that it is redundant, since if the mobile node used bulk registration, the lifetime for all the CoA should be the same, and they would have to be refreshed at the same time and hence be included in the BRR anyway. So I suggest removing the 2nd sentence, and remove the first part of the 3rd sentence -- i.e.: When a node (home agent or correspondent node) sends a Binding Refresh Request for a particular binding created with the BID, the node SHOULD include the Binding Identifier mobility option in the Binding Refresh Request. The sender MAY include multiple Binding Identifier mobility options if there are multiple bindings that need to be refreshed. --- [Section 6.5, pg 30-31] Editorial: Remove "silently" in ..... If no binding is found, the packets MUST be silently discarded. The node MUST also send a Binding Error message as specified in [RFC-3775]. If a BE is sent, it is not a "silently discard". --- I am deferring Sect 8 and Sect 9 for later as I need to read the other drafts more carefully first to understand the interactions. I am, however, curious with the omission of HMIP from this spec. You have Section 7 on NEMO, Section 8 on DSMIP (which is a work-in-progress, so arguably the interaction might change if there are some changes in DSMIP), but nothing is said on HMIP which is already an RFC long ago. /rgds /cwng _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From nemoann@rapidnet.com Sat May 3 05:32:37 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D9B43A6866 for ; Sat, 3 May 2008 05:32:37 -0700 (PDT) X-Quarantine-ID: <5dwNJzbc-KiA> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): From: VIAGRA \256 Official Site [...] X-Spam-Flag: NO X-Spam-Score: -26.233 X-Spam-Level: X-Spam-Status: No, score=-26.233 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_EQ_DYNAMIC=1.144, HELO_EQ_TR=0.935, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MANGLED_OFF=2.3, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dwNJzbc-KiA for ; Sat, 3 May 2008 05:32:37 -0700 (PDT) Received: from dsl85-107-63677.ttnet.net.tr (unknown [85.107.248.189]) by core3.amsl.com (Postfix) with SMTP id 533563A6C7C for ; Sat, 3 May 2008 05:32:35 -0700 (PDT) Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Message-Id: <20080503063418.2680.qmail@dsl85-107-63677.ttnet.net.tr> To: Subject: Dear nemo-archive@ietf.org May 89% 0FF From: VIAGRA ® Official Site MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Sat, 3 May 2008 05:32:35 -0700 (PDT)
Click Here!
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From mext-bounces@ietf.org Sun May 4 14:40:17 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B21C13A6D1C; Sun, 4 May 2008 14:40:16 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84DA83A6F3B for ; Sun, 4 May 2008 14:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Dfi8yxh6spt for ; Sun, 4 May 2008 14:39:59 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 52FE53A6F65 for ; Sun, 4 May 2008 14:38:51 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (164.45.217.87.dynamic.jazztel.es [87.217.45.164])by smtp02.uc3m.es (Postfix) with ESMTP id 0297139C62Efor ; Sun, 4 May 2008 23:38:48 +0200 (CEST) Message-ID: <481E2CE8.2050507@it.uc3m.es> Date: Sun, 04 May 2008 23:38:48 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: mext@ietf.org Content-Type: multipart/mixed; boundary=------------020001040004010002090402 X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-12.7998 TC:1F TRN:45 TV:5.5.1026(15890.002) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: [MEXT] [Fwd: I-D Action:draft-ietf-mext-aaa-ha-goals-01.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --------------020001040004010002090402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi folks, There is a new version of this draft, which addresses all the issues that were discussed in the WGLC. could you verify that this is the cas? we are sending this version of the draft to IESG next week, so please speak up before that if you have a problem Thanks, marcelo -------- Mensaje original -------- Asunto: I-D Action:draft-ietf-mext-aaa-ha-goals-01.txt Fecha: Fri, 2 May 2008 15:00:01 -0700 (PDT) De: Internet-Drafts@ietf.org Responder a: internet-drafts@ietf.org Para: i-d-announce@ietf.org CC: mext@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : AAA Goals for Mobile IPv6 Author(s) : G. Giaretta, et al. Filename : draft-ietf-mext-aaa-ha-goals-01.txt Pages : 12 Date : 2008-05-02 In commercial and enterprise deployments Mobile IPv6 can be a service offered by a Mobility Services Provider (MSP). In this case all protocol operations may need to be explicitly authorized and traced, requiring the interaction between Mobile IPv6 and the AAA infrastructure. Integrating the AAA infrastructure (e.g. NAS and AAA server) offers also a solution component for Mobile IPv6 bootstrapping. This document describes various scenarios where a AAA interface for Mobile IPv6 is required. Additionally, it lists design goals and requirements for such an interface. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-aaa-ha-goals-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------020001040004010002090402 Content-Type: Message/External-body; name="draft-ietf-mext-aaa-ha-goals-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-mext-aaa-ha-goals-01.txt" Content-Type: text/plain Content-ID: <2008-05-02145147.I-D@ietf.org> --------------020001040004010002090402 Content-Type: text/plain; name="file:///var/folders/69/69XC59DYH5yMhl-Hu4+spE+++TI/-Tmp-/nsmail.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="file:///var/folders/69/69XC59DYH5yMhl-Hu4+spE+++TI/-Tmp-/nsm"; filename*1="ail.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------020001040004010002090402 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --------------020001040004010002090402-- From mext-bounces@ietf.org Sun May 4 17:15:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C46F3A6F31; Sun, 4 May 2008 17:15:04 -0700 (PDT) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AFBE83A6F31; Sun, 4 May 2008 17:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080505001501.AFBE83A6F31@core3.amsl.com> Date: Sun, 4 May 2008 17:15:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-nemo-mib-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : NEMO Management Information Base Author(s) : S. Gundavelli, et al. Filename : draft-ietf-mext-nemo-mib-01.txt Pages : 41 Date : 2008-05-04 This memo defines a portion of the Management Information Base (MIB), the network mobility support (NEMO) MIB, for use with network management protocols in the Internet community. In particular, the NEMO MIB will be used to monitor and control a mobile ipv6 node with NEMO functionality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-mib-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-mext-nemo-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-04171445.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Sun May 4 19:25:28 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8847A3A6C19; Sun, 4 May 2008 19:25:28 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B12313A6C19 for ; Sun, 4 May 2008 19:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.509 X-Spam-Level: ** X-Spam-Status: No, score=2.509 tagged_above=-999 required=5 tests=[HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9u1VYCUlEiS for ; Sun, 4 May 2008 19:25:26 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 7F4123A6970 for ; Sun, 4 May 2008 19:25:25 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id m452PEks011785; Mon, 5 May 2008 11:25:14 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb2) with ESMTP id m452PEn16353; Mon, 5 May 2008 11:25:14 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili05) with ESMTP id m452PDI21534; Mon, 5 May 2008 11:25:13 +0900 (JST) Received: from bach.sg.panasonic.com ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 May 2008 10:24:28 +0800 Received: by bach.sg.panasonic.com (Postfix, from userid 1000) id EB237D41CB; Mon, 5 May 2008 10:41:51 +0800 (SGT) From: Chan-Wah Ng To: Rute Sofia In-Reply-To: <47EB8582.6070607@inescporto.pt> References: <47EA6639.4080101@it.uc3m.es> <1206611950.6870.9.camel@localhost> <47EB6FE6.60008@inescporto.pt> <1206616098.6870.37.camel@localhost> <47EB8582.6070607@inescporto.pt> Date: Mon, 05 May 2008 10:41:51 +0800 Message-Id: <1209955311.385.28.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 X-OriginalArrivalTime: 05 May 2008 02:24:28.0980 (UTC) FILETIME=[2536DF40:01C8AE57] Cc: mext Subject: Re: [MEXT] Decisions, and next steps proposed in IETF71 MEXT meeting X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Rute, and all, I have released version 03 for the motivations draft and version 05 for the mip6 analysis draft. Now that we are all in sync, let the comments begin! /rgds /cwng -------- Forwarded Message -------- From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-monami6-multihoming-motivation-scenario-03.txt Date: Fri, 2 May 2008 20:30:01 -0700 (PDT) A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Motivations and Scenarios for Using Multiple Interfaces and Global Addresses Author(s) : T. Ernst, et al. Filename : draft-ietf-monami6-multihoming-motivation-scenario-03.txt Pages : 20 Date : 2008-05-02 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-monami6-multihoming-motivation-scenario-03.txt -------- Forwarded Message -------- From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-monami6-mipv6-analysis-05.txt Date: Fri, 2 May 2008 20:30:01 -0700 (PDT) A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Analysis of Multihoming in Mobile IPv6 Author(s) : N. Montavont, et al. Filename : draft-ietf-monami6-mipv6-analysis-05.txt Pages : 31 Date : 2008-05-02 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-monami6-mipv6-analysis-05.txt On Thu, 2008-03-27 at 11:31 +0000, Rute Sofia wrote: > Hello, > > that were the obvious first steps done but the draft has expired and > there is indeed an update to 03. Not uploaded. So let's wait for what > Thierry states... > > Rute > > George Tsirtsis wrote: > > You can always check the latest published version (expired or not) of > > a draft by googling "tools > > So if you google "tools > > draft-ietf-monami6-multihoming-motivation-scenario" you get a pointer > > to: > > > > http://tools.ietf.org/html/draft-ietf-monami6-multihoming-motivation-scenario-02 > > > > George > > > > On Thu, Mar 27, 2008 at 11:08 AM, Chan-Wah Ng > > wrote: > >> On Thu, 2008-03-27 at 09:59 +0000, Rute Sofia wrote: > >> > Hello, > >> > > >> > cocnerning the scenario draft > >> > , I can only > >> > find version 02. Would it possible to send the URL to version 03? > >> > > >> > >> Well, I see a draft-...-03 in my local cvs directory, I am not sure if > >> the Editor (Thierry) has published it. And none was in IETF repository > >> (expired) ... so I am not sure which was the latest version. > >> > >> Let me check back with Thierry and get back to you. > >> > >> > >> > >> /rgds > >> /cwng > >> > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > >> > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon May 5 21:45:15 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC4F228C3BA; Mon, 5 May 2008 21:45:14 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 979C828C3A4 for ; Mon, 5 May 2008 21:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.564 X-Spam-Level: X-Spam-Status: No, score=-5.564 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-1kXo9DJJYe for ; Mon, 5 May 2008 21:45:10 -0700 (PDT) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by core3.amsl.com (Postfix) with ESMTP id 8A89B28C3BA for ; Mon, 5 May 2008 21:45:08 -0700 (PDT) Received: from ep_ms5_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K0F002BMJUW3P@mailout2.samsung.com> for mext@ietf.org; Tue, 06 May 2008 13:44:56 +0900 (KST) Received: from ep_spt02 (ms5.samsung.com [203.254.225.113]) by ms5.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K0F00J4TJUVNO@ms5.samsung.com> for mext@ietf.org; Tue, 06 May 2008 13:44:55 +0900 (KST) Content-return: prohibited Date: Tue, 06 May 2008 04:44:55 +0000 (GMT) From: Heejin Jang To: Vijay Devarapallli Message-id: <8072825.360421210049095796.JavaMail.weblogic@epml13> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20080506044127253@heejin.jang X-MTR: 20080506044127253@heejin.jang X-EPLocale: ko_KR.utf-8 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML Cc: "mext@ietf.org" Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: heejin.jang@samsung.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Vijay. Sorry for the late reply due to my vacation till yesterday. Thanks for your kind feedback. Please see the below. > -----Original Message----- > From: Vijay Devarapallli [mailto:dvijay@gmail.com] > Sent: Wednesday, April 30, 2008 2:53 PM > To: Jari Arkko; heejin.jang@samsung.com > Cc: mext@ietf.org > Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 > > Hi Jari, Heejin, > > Its been a while since I looked at this document. A few minor > comments. > > The IANA registry for the sub-opt-code in the Home Network > Information option and the MIP6 Relay agent option should be > relaxed to "Standards Action or IESG approval". It would be > good if the sub-opt-code can be extended to carry additional > pieces of information using Experimental or Informational > RFCs in the future. Mentioning "Standards Action" > means the sub-opt-code can only be extended by Standards Track RFCs. > This would require a minor change in the IANA considerations section. Ok. It will be reflected in next version. > I think a new registry should be created for the Id-type > field in the Home Network Information option (section 3.1). > This is missing in the IANA considerations section. Ok. It will be reflected as below. In Section 6, Old: In addition, a new name space "Home Network Information Option Id-type Values" should be created, again in the same registry. Values 0, 1, and 2 are assigned by this document as specified in Section 3.1. New: IANA is requested to create a new registry for the Home Network Information Option Id-type Codes. o Visited domain (local ASP) 0 o Target MSP 1 o No preference by the mobile node 2 > Another minor comment related to this. > The value '0' should be used to indicate that the MN has no > preference, instead of the value '2' being used for no > preference and '0' used for visited domain home agent > information. That seems more conventional. But if this needs > too many changes in the document, don' > t bother. It makes sense. But the authors and AD worry about much changes, so hope to keep as it is unless it causes any problem. > Finally, the introduction needs to be slightly re-written to > say that the main goal of this document is to deliver the > home agent information to the mobile node using stateless > DHCPv6. It currently seems to say that the mail goal is to > deliver a prefix so that the mobile node can run DHAAD using > that prefix. I don't remember if the introduction always used > to say this or if it was changed recently. Ok. We mentioned the goal of the document clearly in the Section 1. Old: ... Subsequently, the mobile node can engage in dynamic home agent discovery using the prefix information. In addition to delivering the prefix information, DHCP can also be used to provide the IP addresses or FQDNs of the home agents that are available to the mobile node. The solution involves defining a new DHCP option to carry home network prefix, home agent IP address and FQDN information. ... New: ... Subsequently, the mobile node can engage in dynamic home agent discovery using the prefix information. In addition to delivering the prefix information, DHCP can also be used to provide the IP addresses or FQDNs of the home agents that are available to the mobile node. The goal of this document is to deliver the home agent information to the mobile node by using stateless DHCPv6. The proposed solution enables it by defining new DHCP options which carry home network prefix, home agent IP address and FQDN information. ... > The document otherwise looks fine. Ready for approval by the IESG. :) Thanks for your concerns again. :) - Best regards, Heejin > Vijay > > On Mon, Apr 21, 2008 at 12:16 AM, Jari Arkko > wrote: > > The last edits are in -15 now. Any additional people who want to > > comment on this before its approved? > > > > Jari > > > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue May 6 08:22:24 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D05703A69AF; Tue, 6 May 2008 08:22:24 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61F1D3A6954 for ; Tue, 6 May 2008 08:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybnLkarJFe1m for ; Tue, 6 May 2008 08:22:22 -0700 (PDT) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.185]) by core3.amsl.com (Postfix) with ESMTP id DDC4B3A69AF for ; Tue, 6 May 2008 08:22:21 -0700 (PDT) Received: by rn-out-0910.google.com with SMTP id e27so921065rng.18 for ; Tue, 06 May 2008 08:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=oZLlXQCnyeMZo52RVTzSBcLhMQPVXahteVaJAIHpwEM=; b=isa+pmKullyR9V1XG1SCsyCQe3Azujj8Ndi7pfkrzoWv9AsIG3bbsGgFZPKKwrM41yazOg/4s0PN2seEliqA2/oAJdm3Cy/xTBhTeFDkS4986Nb8ZVl6iT+Lh4wOpIgpfnr65u9gTwICdcmJQDlMJZLGPGdA8Lx3JIyvPLcJ7iI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=shXSCVXrf4wldG77t3PhTjL5ilg4znDuYl64IAkVR9xaJfRqE3e6bNLfBN46vqM1DoeTOKgtnMVDAzMn9f7rkDGLei5Xaap4b9slPwaCG8mVxVJlViwGlZzEv6QJCH4cSIUyH5ZRnooDeIiHnK5JU+Q0Cu/JqfPK/VxZ0sE1Fbc= Received: by 10.142.58.17 with SMTP id g17mr379468wfa.330.1210087338672; Tue, 06 May 2008 08:22:18 -0700 (PDT) Received: by 10.142.200.13 with HTTP; Tue, 6 May 2008 08:22:18 -0700 (PDT) Message-ID: Date: Tue, 6 May 2008 08:22:18 -0700 From: "Vijay Devarapallli" To: heejin.jang@samsung.com In-Reply-To: <8072825.360421210049095796.JavaMail.weblogic@epml13> MIME-Version: 1.0 Content-Disposition: inline References: <8072825.360421210049095796.JavaMail.weblogic@epml13> Cc: "mext@ietf.org" Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Heejin, Replying to just one issue below (the rest are fine with me) On Mon, May 5, 2008 at 9:44 PM, Heejin Jang wrote: > > Finally, the introduction needs to be slightly re-written to > > say that the main goal of this document is to deliver the > > home agent information to the mobile node using stateless > > DHCPv6. It currently seems to say that the mail goal is to > > deliver a prefix so that the mobile node can run DHAAD using > > that prefix. I don't remember if the introduction always used > > to say this or if it was changed recently. > > Ok. We mentioned the goal of the document clearly in the Section 1. > > Old: > ... > Subsequently, the mobile node can engage in > dynamic home agent discovery using the prefix information. In > addition to delivering the prefix information, DHCP can also be used > to provide the IP addresses or FQDNs of the home agents that are > available to the mobile node. The solution involves defining a new > DHCP option to carry home network prefix, home agent IP address and > FQDN information. > ... > > New: > ... > Subsequently, the mobile node can engage in > dynamic home agent discovery using the prefix information. In > addition to delivering the prefix information, DHCP can also be used > to provide the IP addresses or FQDNs of the home agents that are > available to the mobile node. The goal of this document is to > deliver the home agent information to the mobile node by using > stateless DHCPv6. The proposed solution enables it by defining new > DHCP options which carry home network prefix, home agent IP address > and FQDN information. > ... Not enough. The document needs to clearly state that the main goal is to deliver the home agent information to the mobile node. The mobile node MAY use the prefix to perform DHAAD if it wants to. Thats not the primary goal. How about the following? OLD: Before a mobile node can engage in Mobile IPv6 signaling with a home agent, it should either know the IP address of the home agent via pre-configuration, or dynamically discover it. The Mobile IPv6 specification [RFC3775] describes how home agents can be dynamically discovered by mobile nodes that know the home network prefix. This scheme does not work when prefix information is not already available to the mobile node. One architecture to solve this problem is described in [I-D.ietf-mip6-bootstrapping-integrated-dhc]. A part of the solution is the capability to deliver home network prefix information to the mobile node by means of the stateless DHCPv6 [RFC3736] [RFC3315]. Subsequently, the mobile node can engage in dynamic home agent discovery using the prefix information. In addition to delivering the prefix information, DHCP can also be used to provide the IP addresses or FQDNs of the home agents that are available to the mobile node. The solution involves defining a new DHCP option to carry home network prefix, home agent IP address and FQDN information. NEW: Before a mobile node can engage in Mobile IPv6 signaling with a home agent, it should either know the IP address of the home agent via pre-configuration, or dynamically discover it. The Mobile IPv6 specification [RFC3775] describes how home agents can be dynamically discovered by mobile nodes that know the home network prefix. This scheme does not work when prefix information is not already available to the mobile node. One architecture to solve this problem is described in [I-D.ietf-mip6-bootstrapping-integrated-dhc]. This document specifies extensions to stateless DHCPv6 [RFC3736] [RFC3315] to deliver the home agent information to the mobile node in the form of the IP address of the home agent or the FQDN of the home agent. The information delivered to the mobile node may also include the home prefix for the mobile node. The solution involves defining a new DHCP option to carry home network prefix, home agent IP address and FQDN information. The mobile node MAY also use the home prefix to discover the list of home agents serving the home prefix using the Dynamic Home Agent Address Discovery mechanism specified in RFC 3775. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From fieryskies@hotmail.com Tue May 6 16:51:41 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19F343A6C20 for ; Tue, 6 May 2008 16:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -59.613 X-Spam-Level: X-Spam-Status: No, score=-59.613 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=0.001, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, RELAY_IS_221=2.222, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-7ma9vxTz4z for ; Tue, 6 May 2008 16:51:40 -0700 (PDT) Received: from [221.135.120.54] (unknown [221.135.120.54]) by core3.amsl.com (Postfix) with ESMTP id 4ED1E28C479 for ; Tue, 6 May 2008 16:50:47 -0700 (PDT) Received: from [221.135.120.54] by mx4.hotmail.com; Tue, 6 May 2008 23:50:44 +0000 Message-ID: <01c8afd3$ff862200$367887dd@fieryskies> From: "Google AdWords-noreply" To: Subject: Account Reactivation. Date: Tue, 6 May 2008 23:50:44 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C8AFD3.FF862200" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C8AFD3.FF862200 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable ----------------------------------------------------------------------- This message was sent from a notification-only email address that does not accept incoming email. Please do not reply to this message. -------------------------------------------------------------------------= - Dear Google AdWords Customer, We were unable to process your payment. Your ads will be suspended soon unless we can process your payment. To prevent your ads from being suspended, please update your payment info= rmation. Please sign in to your account at http://adwords.google.com/select/login, and update your payment information. -------------------------------------------------------------------------= - We look forward to providing you with the most effective advertising avai= lable. Thank you for choosing AdWords. ------=_NextPart_000_0007_01C8AFD3.FF862200 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable ----------------------------------------------------------------------- This message was sent from a notification-only email address that does not accept incoming email. Please do not reply to this message.
-------------------------------------------------------------------------= --
Dear Google AdWords Customer,

We were unable to process your payment.
Your ads will be suspended soon unless we can process your payment.
To prevent your ads from being suspended, please update your payment info= rmation.

Please sign in
to your account at http://adwords.google.com/select/login,
and update your payment information.

------------------------------------------------------------------------<= br> We look forward to providing you with the most effective advertising avai= lable.
Thank you for choosing AdWords.
------------------------------------------------------------------------<= br> ------=_NextPart_000_0007_01C8AFD3.FF862200-- From mext-bounces@ietf.org Wed May 7 01:01:17 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 881AD3A7103; Wed, 7 May 2008 01:01:16 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29BEC3A6DB3 for ; Wed, 7 May 2008 01:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KrEpIFEp8Ig for ; Wed, 7 May 2008 01:01:03 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id 2537B28C54A for ; Wed, 7 May 2008 00:59:21 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so223736rvf.49 for ; Wed, 07 May 2008 00:59:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=/m01TBL5xbEtctNYf9b3BA0UfNGrRZ0aOlJ63wU4nHs=; b=atdsduOdvVA66KDLaw9GdBAhkHmYStbwFgd3lLYD+WC/WyDGffD9r+KneQZuW9Km8G37SRAA2i4wHLByI0k0zTOqYByL+5GKxZDASPoNLlqFFC9cCzcUnmgJUaHPDyHvEzZRjkclTJBKhSBOUMs1pAi/pSOnttu2XKRkk60g+Eg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=vksIert22mLmqPhjHwLwFQNwtPNFatA47mdJzf9XjOYqA6DUl3rTFOjupif8liBULa5tz0F3yEUSAUTsM0k1sJyTqLD/qryBRwOXqqhdHA6ZPNE+XZ6uwWJkSJGXNfKnhQjGlfEHK1/Nv7TC5cMYwHdW7yjJ9/T/k4bd0fuMjF4= Received: by 10.142.57.18 with SMTP id f18mr725190wfa.308.1210147159053; Wed, 07 May 2008 00:59:19 -0700 (PDT) Received: by 10.142.177.9 with HTTP; Wed, 7 May 2008 00:59:18 -0700 (PDT) Message-ID: Date: Wed, 7 May 2008 08:59:18 +0100 From: "George Tsirtsis" To: "Julien Laganier" , "marcelo bagnulo" In-Reply-To: <20080501181501.BCA813A68CC@core3.amsl.com> MIME-Version: 1.0 Content-Disposition: inline References: <20080501181501.BCA813A68CC@core3.amsl.com> Cc: "mext@ietf.org" Subject: [MEXT] Fwd: I-D ACTION:draft-ietf-mext-nemo-v4traversal-02.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien/Marcelo et.al., Are we done with the WGLC for this ? Anything else needed before we progress this further? Thanks George ---------- Forwarded message ---------- From: Date: 2008/5/1 Subject: I-D ACTION:draft-ietf-mext-nemo-v4traversal-02.txt To: i-d-announce@ietf.org Cc: mext@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6) Author(s) : H. Soliman Filename : draft-ietf-mext-nemo-v4traversal-02.txt Pages : 48 Date : 2008-5-1 The current Mobile IPv6 and NEMO specifications support IPv6 only. This specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the home agent. This specification also allows the Mobile Node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path between the mobile node and its home agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-v4traversal-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed May 7 11:12:46 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C0D63A6A64; Wed, 7 May 2008 11:12:43 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D6BC28C711 for ; Wed, 7 May 2008 11:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmE-18nddiVE for ; Wed, 7 May 2008 11:11:36 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 53B0E28C6E6 for ; Wed, 7 May 2008 11:10:29 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m47IAPIE008977 for ; Wed, 7 May 2008 13:10:25 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 May 2008 13:10:25 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 May 2008 13:10:25 -0500 Message-ID: <4821F071.1000400@ericsson.com> Date: Wed, 07 May 2008 14:09:53 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: mext@ietf.org Content-Type: multipart/mixed; boundary="------------030407090904090207070406" X-OriginalArrivalTime: 07 May 2008 18:10:25.0517 (UTC) FILETIME=[9F92A1D0:01C8B06D] Subject: [MEXT] New versions (-04) of the firewall vendor and admin drafts X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --------------030407090904090207070406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Folks, We have submitted new versions of the firewall vendor guidelines and the administrator guidelines drafts to address the issues raised during the earlier reviews and during the IETF71 mext meeting. Please take a look and let us know if you have any comments or issues. Thanks Suresh -------- Original Message -------- Subject: I-D Action:draft-krishnan-mip6-firewall-admin-04.txt Date: Wed, 30 Apr 2008 08:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Guidelines for firewall administrators regarding MIPv6 traffic Author(s) : S. Krishnan, et al. Filename : draft-krishnan-mip6-firewall-admin-04.txt Pages : 12 Date : 2008-04-30 This document presents some recommendations for firewall administrators to help them configure their existing firewalls in a way that allows in certain deployment scenarios the Mobile IPv6 signaling and data messages to pass through. For other scenarios, the support of additional mechanisms to create pinholes required for MIPv6 will be necessary. This document assumes that the firewalls in question include some kind of stateful packet filtering capability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-krishnan-mip6-firewall-admin-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------- Original Message -------- Subject: I-D Action:draft-krishnan-mip6-firewall-vendor-04.txt Date: Wed, 30 Apr 2008 08:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Guidelines for firewall vendors regarding MIPv6 traffic Author(s) : S. Krishnan, et al. Filename : draft-krishnan-mip6-firewall-vendor-04.txt Pages : 8 Date : 2008-04-30 This document presents some recommendations for firewall vendors to help them implement their firewalls in a way that allows Mobile IPv6 signaling and data messages to pass through. This document describes how to implement stateful packet filtering capability for MIPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-krishnan-mip6-firewall-vendor-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------030407090904090207070406 Content-Type: Message/External-body; name="draft-krishnan-mip6-firewall-vendor-04.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-krishnan-mip6-firewall-vendor-04.txt" Content-Type: text/plain Content-ID: <2008-04-30083124.I-D@ietf.org> --------------030407090904090207070406 Content-Type: text/plain; name="file:///tmp/nsmail-1.asc" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///tmp/nsmail-1.asc" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------030407090904090207070406 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --------------030407090904090207070406-- From mext-bounces@ietf.org Wed May 7 12:00:52 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0463428C741; Wed, 7 May 2008 12:00:52 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D48A28C72F for ; Wed, 7 May 2008 12:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mizs-qOI8nS0 for ; Wed, 7 May 2008 12:00:41 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 7C7093A6DDF for ; Wed, 7 May 2008 12:00:19 -0700 (PDT) Received: from localhost (webcartero01.uc3m.es [163.117.136.131])by smtp01.uc3m.es (Postfix) with ESMTP id C04F65C401Cfor ; Wed, 7 May 2008 20:55:30 +0200 (CEST) Received: from 163.117.203.42 ([163.117.203.42]) by webcartero01.uc3m.es(Horde MIME library) with HTTP; Wed, 07 May 2008 20:55:28 +0200 Message-ID: <20080507205528.sorn6iepm8o48c8c@webcartero01.uc3m.es> Date: Wed, 07 May 2008 20:55:28 +0200 From: MARCELO BAGNULO BRAUN To: mext@ietf.org References: <4821F071.1000400@ericsson.com> In-Reply-To: <4821F071.1000400@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-16.1823 TC:1F TRN:49 TV:5.5.1026(15896.001) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: Re: [MEXT] New versions (-04) of the firewall vendor and admindrafts X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, As you know, we have a deliverable in our charter that covers the firewall MIPv6 work. Julien and myslef would like to know if people are ok with accepting these document as WG items for this charter items. Please comment. Thanks, Julien and marcelo Suresh Krishnan dijo: > Hi Folks, > We have submitted new versions of the firewall vendor guidelines > and the administrator guidelines drafts to address the issues raised > during the earlier reviews and during the IETF71 mext meeting. Please > take a look and let us know if you have any comments or issues. > > Thanks > Suresh > > -------- Original Message -------- > Subject: I-D Action:draft-krishnan-mip6-firewall-admin-04.txt > Date: Wed, 30 Apr 2008 08:45:02 -0700 (PDT) > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Guidelines for firewall administrators regarding > MIPv6 traffic > Author(s) : S. Krishnan, et al. > Filename : draft-krishnan-mip6-firewall-admin-04.txt > Pages : 12 > Date : 2008-04-30 > > This document presents some recommendations for firewall > administrators to help them configure their existing firewalls in a > way that allows in certain deployment scenarios the Mobile IPv6 > signaling and data messages to pass through. For other scenarios, > the support of additional mechanisms to create pinholes required for > MIPv6 will be necessary. This document assumes that the firewalls in > question include some kind of stateful packet filtering capability. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-krishnan-mip6-firewall-admin-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > -------- Original Message -------- > Subject: I-D Action:draft-krishnan-mip6-firewall-vendor-04.txt > Date: Wed, 30 Apr 2008 08:45:02 -0700 (PDT) > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Guidelines for firewall vendors regarding MIPv6 traffic > Author(s) : S. Krishnan, et al. > Filename : draft-krishnan-mip6-firewall-vendor-04.txt > Pages : 8 > Date : 2008-04-30 > > This document presents some recommendations for firewall vendors to > help them implement their firewalls in a way that allows Mobile IPv6 > signaling and data messages to pass through. This document describes > how to implement stateful packet filtering capability for MIPv6. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-krishnan-mip6-firewall-vendor-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 8 08:43:21 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04B873A7394; Thu, 8 May 2008 08:43:21 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3B973A738D for ; Thu, 8 May 2008 08:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.688 X-Spam-Level: X-Spam-Status: No, score=-4.688 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHH-E7gyZssV for ; Thu, 8 May 2008 08:43:18 -0700 (PDT) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by core3.amsl.com (Postfix) with ESMTP id 6EB2528CC11 for ; Thu, 8 May 2008 06:34:23 -0700 (PDT) Received: from ep_ms5_bk (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K0J00K9TRLTWL@mailout3.samsung.com> for mext@ietf.org; Thu, 08 May 2008 20:22:41 +0900 (KST) Received: from ep_spt01 (ms5.samsung.com [203.254.225.113]) by ms5.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K0J002JRRLTDX@ms5.samsung.com> for mext@ietf.org; Thu, 08 May 2008 20:22:41 +0900 (KST) Content-return: prohibited Date: Thu, 08 May 2008 11:22:41 +0000 (GMT) From: Heejin Jang To: Vijay Devarapallli Message-id: <1967984.510541210245761238.JavaMail.weblogic@epml15> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20080508112041758@heejin.jang X-MTR: 20080508112041758@heejin.jang X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML Cc: "mext@ietf.org" Subject: Re: [MEXT] FW: Summary for the changes in hiopt-13 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: heejin.jang@samsung.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I see. Now I can know what you meant. The proposed text looks good and I'll reflect it in the next version. Thanks for your kind help again. :) - Best regards, Heejin. ------- Original Message ------- Sender : Vijay Devarapallli Date : 2008-05-07 00:22 (GMT+09:00) Title : Re: Re: [MEXT] FW: Summary for the changes in hiopt-13 Hi Heejin, Replying to just one issue below (the rest are fine with me) On Mon, May 5, 2008 at 9:44 PM, Heejin Jang wrote: > > Finally, the introduction needs to be slightly re-written to > > say that the main goal of this document is to deliver the > > home agent information to the mobile node using stateless > > DHCPv6. It currently seems to say that the mail goal is to > > deliver a prefix so that the mobile node can run DHAAD using > > that prefix. I don't remember if the introduction always used > > to say this or if it was changed recently. > > Ok. We mentioned the goal of the document clearly in the Section 1. > > Old: > ... > Subsequently, the mobile node can engage in > dynamic home agent discovery using the prefix information. In > addition to delivering the prefix information, DHCP can also be used > to provide the IP addresses or FQDNs of the home agents that are > available to the mobile node. The solution involves defining a new > DHCP option to carry home network prefix, home agent IP address and > FQDN information. > ... > > New: > ... > Subsequently, the mobile node can engage in > dynamic home agent discovery using the prefix information. In > addition to delivering the prefix information, DHCP can also be used > to provide the IP addresses or FQDNs of the home agents that are > available to the mobile node. The goal of this document is to > deliver the home agent information to the mobile node by using > stateless DHCPv6. The proposed solution enables it by defining new > DHCP options which carry home network prefix, home agent IP address > and FQDN information. > ... Not enough. The document needs to clearly state that the main goal is to deliver the home agent information to the mobile node. The mobile node MAY use the prefix to perform DHAAD if it wants to. Thats not the primary goal. How about the following? OLD: Before a mobile node can engage in Mobile IPv6 signaling with a home agent, it should either know the IP address of the home agent via pre-configuration, or dynamically discover it. The Mobile IPv6 specification [RFC3775] describes how home agents can be dynamically discovered by mobile nodes that know the home network prefix. This scheme does not work when prefix information is not already available to the mobile node. One architecture to solve this problem is described in [I-D.ietf-mip6-bootstrapping-integrated-dhc]. A part of the solution is the capability to deliver home network prefix information to the mobile node by means of the stateless DHCPv6 [RFC3736] [RFC3315]. Subsequently, the mobile node can engage in dynamic home agent discovery using the prefix information. In addition to delivering the prefix information, DHCP can also be used to provide the IP addresses or FQDNs of the home agents that are available to the mobile node. The solution involves defining a new DHCP option to carry home network prefix, home agent IP address and FQDN information. NEW: Before a mobile node can engage in Mobile IPv6 signaling with a home agent, it should either know the IP address of the home agent via pre-configuration, or dynamically discover it. The Mobile IPv6 specification [RFC3775] describes how home agents can be dynamically discovered by mobile nodes that know the home network prefix. This scheme does not work when prefix information is not already available to the mobile node. One architecture to solve this problem is described in [I-D.ietf-mip6-bootstrapping-integrated-dhc]. This document specifies extensions to stateless DHCPv6 [RFC3736] [RFC3315] to deliver the home agent information to the mobile node in the form of the IP address of the home agent or the FQDN of the home agent. The information delivered to the mobile node may also include the home prefix for the mobile node. The solution involves defining a new DHCP option to carry home network prefix, home agent IP address and FQDN information. The mobile node MAY also use the home prefix to discover the list of home agents serving the home prefix using the Dynamic Home Agent Address Discovery mechanism specified in RFC 3775. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 8 19:06:22 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 363E43A67A1; Thu, 8 May 2008 19:06:22 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAFF63A67A1 for ; Thu, 8 May 2008 19:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjWx6Og9slL7 for ; Thu, 8 May 2008 19:06:19 -0700 (PDT) Received: from mail2.ics.ntts.co.jp (mail2.ics.ntts.co.jp [202.32.24.42]) by core3.amsl.com (Postfix) with ESMTP id D31353A63CB for ; Thu, 8 May 2008 19:06:15 -0700 (PDT) Received: from sadoku34.silk.ntts.co.jp (sadoku34 [10.7.18.34]) by mail2.ics.ntts.co.jp (8.13.8/NTTSOFT) with ESMTP id m49262ld015839; Fri, 9 May 2008 11:06:02 +0900 (JST) Received: (from root@localhost) by sadoku34.silk.ntts.co.jp (8.13.8/NTTSOFT) id m49262gf012161; Fri, 9 May 2008 11:06:02 +0900 (JST) Received: from mail28.silk.ntts.co.jp [10.7.18.28] by sadoku34.silk.ntts.co.jp with SMTP id MAA12098; Fri, 9 May 2008 11:05:47 +0900 Received: from localhost (localhost [127.0.0.1]) by mail28.silk.ntts.co.jp (8.13.8/8.13.7/NTTSOFT) with ESMTP id m4925lNf005187; Fri, 9 May 2008 11:05:47 +0900 (JST) Date: Fri, 09 May 2008 11:05:55 +0900 (JST) Message-Id: <20080509.110555.670305960.takamiya@po.ntts.co.jp> To: suresh.krishnan@ericsson.com From: Noriaki TAKAMIYA In-Reply-To: <4821F071.1000400@ericsson.com> References: <4821F071.1000400@ericsson.com> X-Face: +<)&j!Ce24nM@a.\f6TA, ]^9Q76[_QN_[QR-(bT&>b40Oo[:`R(>b7!b-|q5k&.8CO[_Oh_ !9Nk0rikK70~?|08EFH|:]iF6pwPlnfEn-wo-voY:rP?%7p%cxjnbf'hglO'se&QwZN7/RVX!U7*P% cTV('HfHp+?g1+hx7\+J.W]G zYWv%LsDc X-Mailer: Mew version 5.2 on XEmacs 21.4.19 (Constant Variable) Mime-Version: 1.0 Cc: mext@ietf.org Subject: Re: [MEXT] New versions (-04) of the firewall vendor and admin drafts X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, >> Wed, 07 May 2008 14:09:53 -0400 >> [Subject: [MEXT] New versions (-04) of the firewall vendor and admin drafts] >> Suresh Krishnan wrote... > Hi Folks, > We have submitted new versions of the firewall vendor guidelines and > the administrator guidelines drafts to address the issues raised during > the earlier reviews and during the IETF71 mext meeting. Please take a > look and let us know if you have any comments or issues. I'v not been the meeting for a long time, and if it is insufficient, correct me. Firewall configuration for MIPv6 is also described in RFC4890 and RFC4942. How about refer to these document? example) 4.3.2 in RFC4890 2.1.2, 2.1.15 in RFC4942 Regareds, -- Noriaki TAKAMIYA _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri May 9 00:22:28 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51D843A67FB; Fri, 9 May 2008 00:22:28 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F24AB3A67FB for ; Fri, 9 May 2008 00:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxGyrrdHA4HE for ; Fri, 9 May 2008 00:22:26 -0700 (PDT) Received: from ws000774.tietoenator.com (ws000774.tietoenator.com [193.12.181.129]) by core3.amsl.com (Postfix) with ESMTP id F3DF63A67B0 for ; Fri, 9 May 2008 00:22:25 -0700 (PDT) X-AuditID: c10cb581-000006c4000004dc-09-4823fae56492 Received: from stingray.eu.tieto.com ([192.176.143.13]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 May 2008 09:19:01 +0200 Received: from corvette.eu.tieto.com ([192.176.143.143]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 May 2008 09:19:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 May 2008 09:19:08 +0200 Message-ID: In-Reply-To: <20080501181501.BCA813A68CC@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DSMIP when returning home thread-index: Acirt5FvjMoZ22ZZRPCBxOKPyZ/FJQF7EAJQ References: <20080501181501.BCA813A68CC@core3.amsl.com> From: To: X-OriginalArrivalTime: 09 May 2008 07:19:08.0720 (UTC) FILETIME=[F8D01B00:01C8B1A4] X-Brightmail-Tracker: AAAAAA== Subject: [MEXT] DSMIP when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org When a mobile node returns home and sends the de-registration binding update, is it correct, that the mobile node SHOULD NOT include the IPv4 Home Address mobility option (and thus the home agent should not in its binding acknowledgement include the IPv4 Address Acknowledgement mobility option)? Christian _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri May 9 04:05:01 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A8783A684B; Fri, 9 May 2008 04:05:01 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E269B3A684B for ; Fri, 9 May 2008 04:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xKmaRTkKCsk for ; Fri, 9 May 2008 04:04:58 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 99E983A681E for ; Fri, 9 May 2008 04:04:58 -0700 (PDT) Received: from IBM52A5038A94F (dsl88-247-34287.ttnet.net.tr [88.247.133.239]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1JuPod2Ihq-0003Of; Fri, 09 May 2008 06:27:11 -0400 From: "Alper Yegin" To: "'Alexandru Petrescu'" , Date: Fri, 9 May 2008 13:26:55 +0300 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Aciqpoc4yd2kvSu6RB+JUw0RkvyaEQHGBqug In-Reply-To: <48183EC6.7000301@gmail.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Message-Id: <0MKpCa-1JuPod2Ihq-0003Of@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/CTTkiI3kJClI3mNZ+970ZyGN79hE93L+NprK uxqMpLSqoTZvv8dycAZ9yfx8mIIKWDCQHb/SCQcqRsAvm4akCl N5sbadJ/m6PzcXIIZMZig== Cc: lprosee@gmail.com, mext@ietf.org Subject: Re: [MEXT] why having DHCP do DNS resolution? (was: FW: Summary for the changes in hiopt-13) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Alex, The issue at hand is roaming, and identification of realm (as opposed to identification of the host). That's what the realm portion of the NAI is for (in other IETF specs), and that's how it is also used in this spec as well. I hope this clarifies. Alper Samsung > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Alexandru Petrescu > Sent: Wednesday, April 30, 2008 12:41 PM > To: heejin.jang@samsung.com > Cc: lprosee@gmail.com; mext@ietf.org > Subject: Re: [MEXT] why having DHCP do DNS resolution? (was: FW: Summary > for the changes in hiopt-13) > > Heejin Jang wrote: > > Hi, Alex. See below. > > > > ps> I'm supposed to have a vacation till next Monday, and cannot > > access my samsung account. So kindly refer my gmail account as well. > > Heejin, enjoy vacations :-) when back in office see below. > > [...] > >> Then I don't see why stateless DHCPv6 is needed for this? Plain > >> full DHCPv6 can accommodate this scenario. > > > > Basically plain (stateful) DHCPv6 is used for address configuration > > while stateless DHCPv6 is for other parameters configuration such as > > DNS server address. So this HN information should be delivered > > through stateless DHCPv6. > > Let's clarify this use of Stateless DHCPv6 RFC3736. > > Why does a hiopt MN need to include a Home Network Identifier > (Sub-Opt-Code 1, eg realm of NAI) in the Home Network Information Option > in the Information-Request? Why isn't it sufficient to use the Client > Identifier Option DUID section 22.2 of RFC 3315 DHCPv6. > > Why isn't the DUID enough to identify the Client (1 - Link-layer address > plus time, 2 - vendor-assigned unique id based on enterprise number, 3 - > link-layer address). > > Why is it thought that it is necessary to specify Home Network > Identifier Sub-Opt-Code 1 as being, for example, the realm part of a > NAI, when the DUID exists, is used and covers a different range of cases. > > >>>> I think that RFC doesn't suggest the Client to put data in a > >>>> request and the Server to suggest back a different data. Or, > >>>> apparently, a hiopt-13 Client puts IPv6 home network prefix in > >>>> a Request, with sub-opt-code equal 2, Relay forwards it to > >>>> Server, and Server puts another IPv6 home network prefix in a > >>>> Reply, apparently. Is this the intended hiop-13 behaviour? > >>>> > >>>> Is this behaviour in this sense completely different than the > >>>> typical > >>>> > >>>> DHCPv6 operation? > >>> > >>> Section 3.3 says > >>> > >>> " While the Sub-opt-code 1 is only available in both the > >>> requesting and the returned Home Network Information options, > >>> Sub-opt-codes 2, 3, 4, and 5 are available only in the returned > >>> Home Network Information option and the MIP6 Relay Agent option." > >>> > >>> > >>> > >>> > >>> > >>> Section 4.1 says > >>> > >>> " A value of 1 is the only Sub-opt-code available in the > >>> request." > > Right, now makes better sense. For easing my humble reading this > statement could appear in section 3.1 where the message encoding of Home > Network Information Option is described. > > >>> An MN cannot carry sub-opt-codes other than 1. This means that a > >>> sub-option in the request is used only to carry the MN's > >>> prefered target MSP in case of id-type 1 so that the server can > >>> reply the matching HA information. > >>> > >>> So, the server never replys with "the different" data. > >> Right, thanks, now I understand it better as being the basic hiopt > >> behaviour. > >> > >> Let me agree with you for a short while that it's good to identify > >> the subnet by a FQDN. > >> > >> If so basically MN (DHCP Client) puts FQDN in the request and the > >> DHCP Server sends back an IP address of the Home Agent. > >> > >> How is this different than DNS Resolution? Why do we need DHCP to > >> do DNS Resolution? > > > > While MNs are required to know an exact FQDN of the target (HA) for > > DNS resolution, DHCP discovery enables HA discovery in variable ways > > even in case MN does not have exact information about its home > > network. For e.g. it can request the local HAs with the id-type 0. Or > > the server may return partially matching HA information as described > > in Section 4.3. > > I agree at high level but not in detail. > > The really big problem here - and in all bootstrapping documents - is > that we have not precisely described what is the information available > at the MN prior to bootstrapping phase. Different documents make > different assumptions and they overlap. > > [skipped some for focusing the discussion] > > > IMHO, such a load-balancing approach is wellknown and does not need > > to be limited to VPN. Anyway here the key point is "to provide HA > > information based on NAI" can be implemented in various ways as least > > by using 1) and 2) as described in previous mails. > > If it is the key point then it should be much more clear than that. > It is far from being clear. Now here it's said "NAI" but in the > document it's said "for example, the realm part of NAI". If we decide > to do only NAI-based HA address bootstrapping with DHCPv6 then I can > agree we can have a better document. > > That is a big if. > > Because - does DHCPv6 or DHCPv4 ever use NAI for address allocation or > parameter configuration? I don't think so. They use MAC address (or > DUID) but not NAI. I find hiopt very much different than DHCPv6 in this > sense. IMHO. ?. > > If one wants to use NAI (or its realm part) to find the corresponding IP > address then use DNS straight resolution, not DHCP. > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri May 9 06:03:59 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 177FA3A67B6; Fri, 9 May 2008 06:03:59 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1A713A67B6 for ; Fri, 9 May 2008 06:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[AWL=0.596, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DZ+aRD5I0Ih for ; Fri, 9 May 2008 06:03:56 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 44AB03A67FA for ; Fri, 9 May 2008 06:03:55 -0700 (PDT) Received: from [124.190.105.201] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1JuPTF-0003p2-EK; Fri, 09 May 2008 20:04:57 +1000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Fri, 09 May 2008 20:04:51 +1000 From: Hesham Soliman To: , Message-ID: Thread-Topic: [MEXT] DSMIP when returning home Thread-Index: Acirt5FvjMoZ22ZZRPCBxOKPyZ/FJQF7EAJQAAYTWmQ= In-Reply-To: Mime-version: 1.0 Subject: Re: [MEXT] DSMIP when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Technically it doesn't matter because the SA is tied to the IPv6 address, so removing the IPv6 HoA binding must remove all bindings. Hesham On 9/05/08 5:19 PM, "Christian.Kaas-Petersen@tietoenator.com" wrote: > When a mobile node returns home and sends the de-registration binding > update, is it correct, that the mobile node SHOULD NOT > include the IPv4 Home Address mobility option (and thus the home > agent should not in its binding acknowledgement include the > IPv4 Address Acknowledgement mobility option)? > > Christian > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri May 9 08:31:53 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 772383A6866; Fri, 9 May 2008 08:31:53 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 003043A6866 for ; Fri, 9 May 2008 08:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPlL5MYWsuPA for ; Fri, 9 May 2008 08:31:51 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id DFE6E3A67CE for ; Fri, 9 May 2008 08:31:50 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 May 2008 11:17:10 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] DSMIP when returning home Thread-Index: Acirt5FvjMoZ22ZZRPCBxOKPyZ/FJQF7EAJQABDZSPA= References: <20080501181501.BCA813A68CC@core3.amsl.com> From: "Vijay Devarapalli" To: , Subject: Re: [MEXT] DSMIP when returning home X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Christian.Kaas-Petersen@tietoenator.com > Sent: Friday, May 09, 2008 12:19 AM > To: mext@ietf.org > Subject: [MEXT] DSMIP when returning home > > When a mobile node returns home and sends the de-registration binding > update, is it correct, that the mobile node SHOULD NOT > include the IPv4 Home Address mobility option (and thus the home > agent should not in its binding acknowledgement include the > IPv4 Address Acknowledgement mobility option)? That's correct. There is no harm in including it though. It won't result in the home agent processing the de-registration BU differently. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri May 9 13:14:50 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BABD3A6801; Fri, 9 May 2008 13:14:50 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1D4B3A6801 for ; Fri, 9 May 2008 13:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZYST3jtQ9uX for ; Fri, 9 May 2008 13:14:47 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 7D2333A67CE for ; Fri, 9 May 2008 13:14:44 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-153.messagelabs.com!1210363885!9839591!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 18460 invoked from network); 9 May 2008 20:11:25 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-12.tower-153.messagelabs.com with SMTP; 9 May 2008 20:11:25 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id m49KBLhq016328; Fri, 9 May 2008 13:11:21 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id m49KBKP1013418; Fri, 9 May 2008 15:11:20 -0500 (CDT) Received: from [127.0.0.1] ([10.129.40.15]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id m49KBHUi013378; Fri, 9 May 2008 15:11:18 -0500 (CDT) Message-ID: <4824AFE4.2060804@gmail.com> Date: Fri, 09 May 2008 22:11:16 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Alper Yegin References: <0MKpCa-1JuPod2Ihq-0003Of@mrelay.perfora.net> In-Reply-To: <0MKpCa-1JuPod2Ihq-0003Of@mrelay.perfora.net> X-Antivirus: avast! (VPS 080508-0, 08/05/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: lprosee@gmail.com, mext@ietf.org Subject: Re: [MEXT] why having DHCP do DNS resolution? (was: FW: Summary for the changes in hiopt-13) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Alper Yegin wrote: > Hi Alex, > > The issue at hand is roaming, and identification of realm (as opposed to > identification of the host). That's what the realm portion of the NAI is for > (in other IETF specs), and that's how it is also used in this spec as well. > > I hope this clarifies. Alper - what is 'roaming'? Alex > > Alper > Samsung > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of >> Alexandru Petrescu >> Sent: Wednesday, April 30, 2008 12:41 PM >> To: heejin.jang@samsung.com >> Cc: lprosee@gmail.com; mext@ietf.org >> Subject: Re: [MEXT] why having DHCP do DNS resolution? (was: FW: Summary >> for the changes in hiopt-13) >> >> Heejin Jang wrote: >>> Hi, Alex. See below. >>> >>> ps> I'm supposed to have a vacation till next Monday, and cannot >>> access my samsung account. So kindly refer my gmail account as well. >> Heejin, enjoy vacations :-) when back in office see below. >> >> [...] >>>> Then I don't see why stateless DHCPv6 is needed for this? Plain >>>> full DHCPv6 can accommodate this scenario. >>> Basically plain (stateful) DHCPv6 is used for address configuration >>> while stateless DHCPv6 is for other parameters configuration such as >>> DNS server address. So this HN information should be delivered >>> through stateless DHCPv6. >> Let's clarify this use of Stateless DHCPv6 RFC3736. >> >> Why does a hiopt MN need to include a Home Network Identifier >> (Sub-Opt-Code 1, eg realm of NAI) in the Home Network Information Option >> in the Information-Request? Why isn't it sufficient to use the Client >> Identifier Option DUID section 22.2 of RFC 3315 DHCPv6. >> >> Why isn't the DUID enough to identify the Client (1 - Link-layer address >> plus time, 2 - vendor-assigned unique id based on enterprise number, 3 - >> link-layer address). >> >> Why is it thought that it is necessary to specify Home Network >> Identifier Sub-Opt-Code 1 as being, for example, the realm part of a >> NAI, when the DUID exists, is used and covers a different range of cases. >> >>>>>> I think that RFC doesn't suggest the Client to put data in a >>>>>> request and the Server to suggest back a different data. Or, >>>>>> apparently, a hiopt-13 Client puts IPv6 home network prefix in >>>>>> a Request, with sub-opt-code equal 2, Relay forwards it to >>>>>> Server, and Server puts another IPv6 home network prefix in a >>>>>> Reply, apparently. Is this the intended hiop-13 behaviour? >>>>>> >>>>>> Is this behaviour in this sense completely different than the >>>>>> typical >>>>>> >>>>>> DHCPv6 operation? >>>>> Section 3.3 says >>>>> >>>>> " While the Sub-opt-code 1 is only available in both the >>>>> requesting and the returned Home Network Information options, >>>>> Sub-opt-codes 2, 3, 4, and 5 are available only in the returned >>>>> Home Network Information option and the MIP6 Relay Agent option." >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Section 4.1 says >>>>> >>>>> " A value of 1 is the only Sub-opt-code available in the >>>>> request." >> Right, now makes better sense. For easing my humble reading this >> statement could appear in section 3.1 where the message encoding of Home >> Network Information Option is described. >> >>>>> An MN cannot carry sub-opt-codes other than 1. This means that a >>>>> sub-option in the request is used only to carry the MN's >>>>> prefered target MSP in case of id-type 1 so that the server can >>>>> reply the matching HA information. >>>>> >>>>> So, the server never replys with "the different" data. >>>> Right, thanks, now I understand it better as being the basic hiopt >>>> behaviour. >>>> >>>> Let me agree with you for a short while that it's good to identify >>>> the subnet by a FQDN. >>>> >>>> If so basically MN (DHCP Client) puts FQDN in the request and the >>>> DHCP Server sends back an IP address of the Home Agent. >>>> >>>> How is this different than DNS Resolution? Why do we need DHCP to >>>> do DNS Resolution? >>> While MNs are required to know an exact FQDN of the target (HA) for >>> DNS resolution, DHCP discovery enables HA discovery in variable ways >>> even in case MN does not have exact information about its home >>> network. For e.g. it can request the local HAs with the id-type 0. Or >>> the server may return partially matching HA information as described >>> in Section 4.3. >> I agree at high level but not in detail. >> >> The really big problem here - and in all bootstrapping documents - is >> that we have not precisely described what is the information available >> at the MN prior to bootstrapping phase. Different documents make >> different assumptions and they overlap. >> >> [skipped some for focusing the discussion] >> >>> IMHO, such a load-balancing approach is wellknown and does not need >>> to be limited to VPN. Anyway here the key point is "to provide HA >>> information based on NAI" can be implemented in various ways as least >>> by using 1) and 2) as described in previous mails. >> If it is the key point then it should be much more clear than that. >> It is far from being clear. Now here it's said "NAI" but in the >> document it's said "for example, the realm part of NAI". If we decide >> to do only NAI-based HA address bootstrapping with DHCPv6 then I can >> agree we can have a better document. >> >> That is a big if. >> >> Because - does DHCPv6 or DHCPv4 ever use NAI for address allocation or >> parameter configuration? I don't think so. They use MAC address (or >> DUID) but not NAI. I find hiopt very much different than DHCPv6 in this >> sense. IMHO. ?. >> >> If one wants to use NAI (or its realm part) to find the corresponding IP >> address then use DNS straight resolution, not DHCP. >> >> Alex >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From firaskas@yahoo.com Mon May 12 16:28:19 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BEC23A6767 for ; Mon, 12 May 2008 16:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -47.438 X-Spam-Level: X-Spam-Status: No, score=-47.438 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVuD0lqeGBcJ for ; Mon, 12 May 2008 16:28:18 -0700 (PDT) Received: from [70.22.153.101] (static-70-22-153-101.bos.east.verizon.net [70.22.153.101]) by core3.amsl.com (Postfix) with ESMTP id C69CF28C2A9 for ; Mon, 12 May 2008 16:28:17 -0700 (PDT) Received: from [70.22.153.101] by a.mx.mail.yahoo.com; Mon, 12 May 2008 18:28:15 -0500 Message-ID: <01c8b45d$f1198980$65991646@firaskas> From: "Google-AdWords-noreply" To: Subject: Update Your Billing Information. Date: Mon, 12 May 2008 18:28:15 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C8B45D.F1198980" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C8B45D.F1198980 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable -------------------------------------------------------------------------= -------- Dear Google AdWords Customer, We were unable to process your payment. Your ads will be suspended soon unless we can process your payment. To prevent your ads from being suspended, please update your payment info= rmation. Please sign in to your account at http://adwords.google.com/select/login, and update your payment information. -------------------------------------------------------------------------= ------------------ This message was sent from a notification-only email address that does not accept incoming email. Please do not reply to this message. -------------------------------------------------------------------------= ------------------ We look forward to providing you with the most effective advertising avai= lable. Thank you for choosing AdWords. ------=_NextPart_000_0007_01C8B45D.F1198980 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable -------------------------------------------------------------------------= -------------
Dear Google AdWords Customer,

We were unable to process your payment.
Your ads will be suspended soon unless we can process your payment.
To prevent your ads from being suspended, please update your payment info= rmation.

Please sign in
to your account at http://adwords.google.com/select/login,
and update your payment information.

-------------------------------------------------------------------------= ---------
This message was sent from a notification-only email address that does not accept incoming email. Please do not reply to this message.
-------------------------------------------------------------------------= --
------=_NextPart_000_0007_01C8B45D.F1198980-- From mext-bounces@ietf.org Tue May 13 01:11:35 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 202813A6835; Tue, 13 May 2008 01:11:35 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A19B3A6835 for ; Tue, 13 May 2008 01:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnOz0ysZITNQ for ; Tue, 13 May 2008 01:11:31 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id 252E43A67A5 for ; Tue, 13 May 2008 01:11:30 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so2249249fga.41 for ; Tue, 13 May 2008 01:09:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=967dsv/61RzIddu6pzKuyVUnLjIAHvJE1hce31vjl0o=; b=ZUkugUPKYz49MdDq0ks/y8nvzMsqFbO9RFPhHlv6/GJplPnahQemCUxJTFRAYRBdL5+nafsuVDGJaboet8pXXCXh0BdGc9gjncGQzkdQ4+UoZ3KMKUZM1QgdTNOO5jv1yP1ksGyJXMvuvrDBtcbtFAkBmyasks2Hgh7AdPHoZJo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=GHJW3+BWjAawsUUzbYpJ1SRF1Tmhet/coR/k4qhHYnaRU37si+JDvJbI5fsKHc3KQOod73YEabm1WCGEGFMWjsHmo3mwwQO2Y92Bsd0P9w4y3Gnx1eS1OaOmA2RjJBQE19bC1nnEfu8hjA8X0ICDpQUyvRNldqS+kBYN0vls1fQ= Received: by 10.86.89.4 with SMTP id m4mr15898620fgb.55.1210666195713; Tue, 13 May 2008 01:09:55 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id c28sm13185729fka.4.2008.05.13.01.09.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 13 May 2008 01:09:54 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Tue, 13 May 2008 10:09:46 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <0MKpCa-1JuPod2Ihq-0003Of@mrelay.perfora.net> <4824AFE4.2060804@gmail.com> In-Reply-To: <4824AFE4.2060804@gmail.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200805131009.48693.julien.IETF@laposte.net> Cc: lprosee@gmail.com Subject: Re: [MEXT] why having DHCP do DNS resolution? (was: FW: Summary for the changes in hiopt-13) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Friday 09 May 2008, Alexandru Petrescu wrote: > Alper Yegin wrote: > > Hi Alex, > > > > The issue at hand is roaming, and identification of realm (as > > opposed to identification of the host). That's what the realm > > portion of the NAI is for (in other IETF specs), and that's how it > > is also used in this spec as well. > > > > I hope this clarifies. > > Alper - what is 'roaming'? Alex, do you know Google and/or Wikipedia? --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue May 13 01:40:38 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53E123A6883; Tue, 13 May 2008 01:40:38 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7518B3A6883 for ; Tue, 13 May 2008 01:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEQraGEqRXqE for ; Tue, 13 May 2008 01:40:35 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id AD1A43A67A5 for ; Tue, 13 May 2008 01:40:35 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1210667972!6170867!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 1663 invoked from network); 13 May 2008 08:39:32 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-128.messagelabs.com with SMTP; 13 May 2008 08:39:32 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m4D8dWMd009807; Tue, 13 May 2008 01:39:32 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id m4D8dVBH000685; Tue, 13 May 2008 03:39:31 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id m4D8dTu2000665; Tue, 13 May 2008 03:39:30 -0500 (CDT) Message-ID: <482953C1.9020005@gmail.com> Date: Tue, 13 May 2008 10:39:29 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Julien Laganier References: <0MKpCa-1JuPod2Ihq-0003Of@mrelay.perfora.net> <4824AFE4.2060804@gmail.com> <200805131009.48693.julien.IETF@laposte.net> In-Reply-To: <200805131009.48693.julien.IETF@laposte.net> X-Antivirus: avast! (VPS 080512-0, 12/05/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: mext Subject: Re: [MEXT] why having DHCP do DNS resolution? (was: FW: Summary for the changes in hiopt-13) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Julien Laganier wrote: > On Friday 09 May 2008, Alexandru Petrescu wrote: >> Alper Yegin wrote: >>> Hi Alex, >>> >>> The issue at hand is roaming, and identification of realm (as >>> opposed to identification of the host). That's what the realm >>> portion of the NAI is for (in other IETF specs), and that's how >>> it is also used in this spec as well. >>> >>> I hope this clarifies. >> Alper - what is 'roaming'? > > Alex, do you know Google and/or Wikipedia? > > Ignoring the redirection... Neither Google nor Wikipedia existed when 'Roaming' implementations where described 25 September 1996 draft-aboba-roam-rev which became RFC2194 "Review of Roaming Implementations". That roaming does not use Mobile IP. And why does 'Roaming' need continuous sessions and reachability at a permanent home address? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue May 13 01:42:27 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7C2428C2D4; Tue, 13 May 2008 01:42:26 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BD7128C2D4 for ; Tue, 13 May 2008 01:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O044lKApobv5 for ; Tue, 13 May 2008 01:42:21 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id E49DD28C2C2 for ; Tue, 13 May 2008 01:42:20 -0700 (PDT) Received: from IBM52A5038A94F (dsl88-247-34287.ttnet.net.tr [88.247.133.239]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1Jvq4S2GRP-0003LI; Tue, 13 May 2008 04:41:24 -0400 From: "Alper Yegin" To: "'Alexandru Petrescu'" Date: Tue, 13 May 2008 11:40:51 +0300 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: <4824AFE4.2060804@gmail.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AciyENyUMpjneRbvRTux3HpsD69g0QCw5DTw Message-Id: <0MKpCa-1Jvq4S2GRP-0003LI@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX182K2l/Kg4YySMsfdglQkMMfLRuCJrQ3nzxeEl T7JW8k06QDREiaihfiCx5+rEdnQCDmFn+Jzwr1BR1Sl12cvrDv FHpFuCbJVswnBxKVLuHjw== Cc: lprosee@gmail.com, mext@ietf.org Subject: Re: [MEXT] why having DHCP do DNS resolution? (was: FW: Summary for the changes in hiopt-13) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Alex, Roaming is described where NAI is defined -- RFC 4282. If you see issues let us know. Otherwise let's try to wrap this up. Your thread seems to be the only one holding up this I-D. Thank you for your cooperation. Alper > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Friday, May 09, 2008 11:11 PM > To: Alper Yegin > Cc: heejin.jang@samsung.com; lprosee@gmail.com; mext@ietf.org > Subject: Re: [MEXT] why having DHCP do DNS resolution? (was: FW: Summary > for the changes in hiopt-13) > > Alper Yegin wrote: > > Hi Alex, > > > > The issue at hand is roaming, and identification of realm (as opposed to > > identification of the host). That's what the realm portion of the NAI is > for > > (in other IETF specs), and that's how it is also used in this spec as > well. > > > > I hope this clarifies. > > Alper - what is 'roaming'? > > Alex > > > > > Alper > > Samsung > > > >> -----Original Message----- > >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > >> Alexandru Petrescu > >> Sent: Wednesday, April 30, 2008 12:41 PM > >> To: heejin.jang@samsung.com > >> Cc: lprosee@gmail.com; mext@ietf.org > >> Subject: Re: [MEXT] why having DHCP do DNS resolution? (was: FW: > Summary > >> for the changes in hiopt-13) > >> > >> Heejin Jang wrote: > >>> Hi, Alex. See below. > >>> > >>> ps> I'm supposed to have a vacation till next Monday, and cannot > >>> access my samsung account. So kindly refer my gmail account as well. > >> Heejin, enjoy vacations :-) when back in office see below. > >> > >> [...] > >>>> Then I don't see why stateless DHCPv6 is needed for this? Plain > >>>> full DHCPv6 can accommodate this scenario. > >>> Basically plain (stateful) DHCPv6 is used for address configuration > >>> while stateless DHCPv6 is for other parameters configuration such as > >>> DNS server address. So this HN information should be delivered > >>> through stateless DHCPv6. > >> Let's clarify this use of Stateless DHCPv6 RFC3736. > >> > >> Why does a hiopt MN need to include a Home Network Identifier > >> (Sub-Opt-Code 1, eg realm of NAI) in the Home Network Information > Option > >> in the Information-Request? Why isn't it sufficient to use the Client > >> Identifier Option DUID section 22.2 of RFC 3315 DHCPv6. > >> > >> Why isn't the DUID enough to identify the Client (1 - Link-layer > address > >> plus time, 2 - vendor-assigned unique id based on enterprise number, 3 > - > >> link-layer address). > >> > >> Why is it thought that it is necessary to specify Home Network > >> Identifier Sub-Opt-Code 1 as being, for example, the realm part of a > >> NAI, when the DUID exists, is used and covers a different range of > cases. > >> > >>>>>> I think that RFC doesn't suggest the Client to put data in a > >>>>>> request and the Server to suggest back a different data. Or, > >>>>>> apparently, a hiopt-13 Client puts IPv6 home network prefix in > >>>>>> a Request, with sub-opt-code equal 2, Relay forwards it to > >>>>>> Server, and Server puts another IPv6 home network prefix in a > >>>>>> Reply, apparently. Is this the intended hiop-13 behaviour? > >>>>>> > >>>>>> Is this behaviour in this sense completely different than the > >>>>>> typical > >>>>>> > >>>>>> DHCPv6 operation? > >>>>> Section 3.3 says > >>>>> > >>>>> " While the Sub-opt-code 1 is only available in both the > >>>>> requesting and the returned Home Network Information options, > >>>>> Sub-opt-codes 2, 3, 4, and 5 are available only in the returned > >>>>> Home Network Information option and the MIP6 Relay Agent option." > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Section 4.1 says > >>>>> > >>>>> " A value of 1 is the only Sub-opt-code available in the > >>>>> request." > >> Right, now makes better sense. For easing my humble reading this > >> statement could appear in section 3.1 where the message encoding of > Home > >> Network Information Option is described. > >> > >>>>> An MN cannot carry sub-opt-codes other than 1. This means that a > >>>>> sub-option in the request is used only to carry the MN's > >>>>> prefered target MSP in case of id-type 1 so that the server can > >>>>> reply the matching HA information. > >>>>> > >>>>> So, the server never replys with "the different" data. > >>>> Right, thanks, now I understand it better as being the basic hiopt > >>>> behaviour. > >>>> > >>>> Let me agree with you for a short while that it's good to identify > >>>> the subnet by a FQDN. > >>>> > >>>> If so basically MN (DHCP Client) puts FQDN in the request and the > >>>> DHCP Server sends back an IP address of the Home Agent. > >>>> > >>>> How is this different than DNS Resolution? Why do we need DHCP to > >>>> do DNS Resolution? > >>> While MNs are required to know an exact FQDN of the target (HA) for > >>> DNS resolution, DHCP discovery enables HA discovery in variable ways > >>> even in case MN does not have exact information about its home > >>> network. For e.g. it can request the local HAs with the id-type 0. Or > >>> the server may return partially matching HA information as described > >>> in Section 4.3. > >> I agree at high level but not in detail. > >> > >> The really big problem here - and in all bootstrapping documents - is > >> that we have not precisely described what is the information available > >> at the MN prior to bootstrapping phase. Different documents make > >> different assumptions and they overlap. > >> > >> [skipped some for focusing the discussion] > >> > >>> IMHO, such a load-balancing approach is wellknown and does not need > >>> to be limited to VPN. Anyway here the key point is "to provide HA > >>> information based on NAI" can be implemented in various ways as least > >>> by using 1) and 2) as described in previous mails. > >> If it is the key point then it should be much more clear than that. > >> It is far from being clear. Now here it's said "NAI" but in the > >> document it's said "for example, the realm part of NAI". If we decide > >> to do only NAI-based HA address bootstrapping with DHCPv6 then I can > >> agree we can have a better document. > >> > >> That is a big if. > >> > >> Because - does DHCPv6 or DHCPv4 ever use NAI for address allocation or > >> parameter configuration? I don't think so. They use MAC address (or > >> DUID) but not NAI. I find hiopt very much different than DHCPv6 in > this > >> sense. IMHO. ?. > >> > >> If one wants to use NAI (or its realm part) to find the corresponding > IP > >> address then use DNS straight resolution, not DHCP. > >> > >> Alex > >> > >> > >> ______________________________________________________________________ > >> This email has been scanned by the MessageLabs Email Security System. > >> For more information please visit http://www.messagelabs.com/email > >> ______________________________________________________________________ > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > > > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue May 13 02:58:39 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2084F3A68D2; Tue, 13 May 2008 02:58:39 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B44ED3A68D2 for ; Tue, 13 May 2008 02:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AifCalNHl08P for ; Tue, 13 May 2008 02:58:35 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.245.51]) by core3.amsl.com (Postfix) with SMTP id 1E9543A6837 for ; Tue, 13 May 2008 02:58:35 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1210672670!20325475!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 30134 invoked from network); 13 May 2008 09:57:51 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-7.tower-119.messagelabs.com with SMTP; 13 May 2008 09:57:51 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id m4D9vefQ005396; Tue, 13 May 2008 02:57:45 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id m4D9vdWv009026; Tue, 13 May 2008 04:57:39 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id m4D9va6s009008; Tue, 13 May 2008 04:57:37 -0500 (CDT) Message-ID: <48296610.3030905@gmail.com> Date: Tue, 13 May 2008 11:57:36 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Alper Yegin References: <0MKpCa-1Jvq4S2GRP-0003LI@mrelay.perfora.net> In-Reply-To: <0MKpCa-1Jvq4S2GRP-0003LI@mrelay.perfora.net> X-Antivirus: avast! (VPS 080512-0, 12/05/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: lprosee@gmail.com, mext@ietf.org Subject: Re: [MEXT] why having DHCP do DNS resolution? (was: FW: Summary for the changes in hiopt-13) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Alper - for my clarification about procedure: has hiopt been implemented or prototyped or demoed somehow? It's not my intention to write a thread holding up this I-D. Alex Alper Yegin wrote: > Alex, > > Roaming is described where NAI is defined -- RFC 4282. > > If you see issues let us know. Otherwise let's try to wrap this up. Your > thread seems to be the only one holding up this I-D. > > Thank you for your cooperation. > > Alper > >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Sent: Friday, May 09, 2008 11:11 PM >> To: Alper Yegin >> Cc: heejin.jang@samsung.com; lprosee@gmail.com; mext@ietf.org >> Subject: Re: [MEXT] why having DHCP do DNS resolution? (was: FW: Summary >> for the changes in hiopt-13) >> >> Alper Yegin wrote: >>> Hi Alex, >>> >>> The issue at hand is roaming, and identification of realm (as opposed to >>> identification of the host). That's what the realm portion of the NAI is >> for >>> (in other IETF specs), and that's how it is also used in this spec as >> well. >>> I hope this clarifies. >> Alper - what is 'roaming'? >> >> Alex >> >>> Alper >>> Samsung >>> >>>> -----Original Message----- >>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of >>>> Alexandru Petrescu >>>> Sent: Wednesday, April 30, 2008 12:41 PM >>>> To: heejin.jang@samsung.com >>>> Cc: lprosee@gmail.com; mext@ietf.org >>>> Subject: Re: [MEXT] why having DHCP do DNS resolution? (was: FW: >> Summary >>>> for the changes in hiopt-13) >>>> >>>> Heejin Jang wrote: >>>>> Hi, Alex. See below. >>>>> >>>>> ps> I'm supposed to have a vacation till next Monday, and cannot >>>>> access my samsung account. So kindly refer my gmail account as well. >>>> Heejin, enjoy vacations :-) when back in office see below. >>>> >>>> [...] >>>>>> Then I don't see why stateless DHCPv6 is needed for this? Plain >>>>>> full DHCPv6 can accommodate this scenario. >>>>> Basically plain (stateful) DHCPv6 is used for address configuration >>>>> while stateless DHCPv6 is for other parameters configuration such as >>>>> DNS server address. So this HN information should be delivered >>>>> through stateless DHCPv6. >>>> Let's clarify this use of Stateless DHCPv6 RFC3736. >>>> >>>> Why does a hiopt MN need to include a Home Network Identifier >>>> (Sub-Opt-Code 1, eg realm of NAI) in the Home Network Information >> Option >>>> in the Information-Request? Why isn't it sufficient to use the Client >>>> Identifier Option DUID section 22.2 of RFC 3315 DHCPv6. >>>> >>>> Why isn't the DUID enough to identify the Client (1 - Link-layer >> address >>>> plus time, 2 - vendor-assigned unique id based on enterprise number, 3 >> - >>>> link-layer address). >>>> >>>> Why is it thought that it is necessary to specify Home Network >>>> Identifier Sub-Opt-Code 1 as being, for example, the realm part of a >>>> NAI, when the DUID exists, is used and covers a different range of >> cases. >>>>>>>> I think that RFC doesn't suggest the Client to put data in a >>>>>>>> request and the Server to suggest back a different data. Or, >>>>>>>> apparently, a hiopt-13 Client puts IPv6 home network prefix in >>>>>>>> a Request, with sub-opt-code equal 2, Relay forwards it to >>>>>>>> Server, and Server puts another IPv6 home network prefix in a >>>>>>>> Reply, apparently. Is this the intended hiop-13 behaviour? >>>>>>>> >>>>>>>> Is this behaviour in this sense completely different than the >>>>>>>> typical >>>>>>>> >>>>>>>> DHCPv6 operation? >>>>>>> Section 3.3 says >>>>>>> >>>>>>> " While the Sub-opt-code 1 is only available in both the >>>>>>> requesting and the returned Home Network Information options, >>>>>>> Sub-opt-codes 2, 3, 4, and 5 are available only in the returned >>>>>>> Home Network Information option and the MIP6 Relay Agent option." >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Section 4.1 says >>>>>>> >>>>>>> " A value of 1 is the only Sub-opt-code available in the >>>>>>> request." >>>> Right, now makes better sense. For easing my humble reading this >>>> statement could appear in section 3.1 where the message encoding of >> Home >>>> Network Information Option is described. >>>> >>>>>>> An MN cannot carry sub-opt-codes other than 1. This means that a >>>>>>> sub-option in the request is used only to carry the MN's >>>>>>> prefered target MSP in case of id-type 1 so that the server can >>>>>>> reply the matching HA information. >>>>>>> >>>>>>> So, the server never replys with "the different" data. >>>>>> Right, thanks, now I understand it better as being the basic hiopt >>>>>> behaviour. >>>>>> >>>>>> Let me agree with you for a short while that it's good to identify >>>>>> the subnet by a FQDN. >>>>>> >>>>>> If so basically MN (DHCP Client) puts FQDN in the request and the >>>>>> DHCP Server sends back an IP address of the Home Agent. >>>>>> >>>>>> How is this different than DNS Resolution? Why do we need DHCP to >>>>>> do DNS Resolution? >>>>> While MNs are required to know an exact FQDN of the target (HA) for >>>>> DNS resolution, DHCP discovery enables HA discovery in variable ways >>>>> even in case MN does not have exact information about its home >>>>> network. For e.g. it can request the local HAs with the id-type 0. Or >>>>> the server may return partially matching HA information as described >>>>> in Section 4.3. >>>> I agree at high level but not in detail. >>>> >>>> The really big problem here - and in all bootstrapping documents - is >>>> that we have not precisely described what is the information available >>>> at the MN prior to bootstrapping phase. Different documents make >>>> different assumptions and they overlap. >>>> >>>> [skipped some for focusing the discussion] >>>> >>>>> IMHO, such a load-balancing approach is wellknown and does not need >>>>> to be limited to VPN. Anyway here the key point is "to provide HA >>>>> information based on NAI" can be implemented in various ways as least >>>>> by using 1) and 2) as described in previous mails. >>>> If it is the key point then it should be much more clear than that. >>>> It is far from being clear. Now here it's said "NAI" but in the >>>> document it's said "for example, the realm part of NAI". If we decide >>>> to do only NAI-based HA address bootstrapping with DHCPv6 then I can >>>> agree we can have a better document. >>>> >>>> That is a big if. >>>> >>>> Because - does DHCPv6 or DHCPv4 ever use NAI for address allocation or >>>> parameter configuration? I don't think so. They use MAC address (or >>>> DUID) but not NAI. I find hiopt very much different than DHCPv6 in >> this >>>> sense. IMHO. ?. >>>> >>>> If one wants to use NAI (or its realm part) to find the corresponding >> IP >>>> address then use DNS straight resolution, not DHCP. >>>> >>>> Alex >>>> >>>> >>>> ______________________________________________________________________ >>>> This email has been scanned by the MessageLabs Email Security System. >>>> For more information please visit http://www.messagelabs.com/email >>>> ______________________________________________________________________ >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue May 13 04:34:29 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA64C3A6B81; Tue, 13 May 2008 04:34:29 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77D993A6B81 for ; Tue, 13 May 2008 04:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AxmOLYCz9fh for ; Tue, 13 May 2008 04:34:26 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) by core3.amsl.com (Postfix) with ESMTP id DC5363A65A6 for ; Tue, 13 May 2008 04:34:25 -0700 (PDT) Received: from IBM52A5038A94F (dsl88-247-34287.ttnet.net.tr [88.247.133.239]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1JvskJ2w8j-0003SQ; Tue, 13 May 2008 07:32:49 -0400 From: "Alper Yegin" To: "'Alexandru Petrescu'" Date: Tue, 13 May 2008 14:32:14 +0300 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: <48296610.3030905@gmail.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: Aci039aHyWvrBWElT7iBXzSq+wSsYQACz+uA Message-Id: <0MKpCa-1JvskJ2w8j-0003SQ@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX19veyZ1Vk27c8tjEzgoDsW0/WWQdMUWD8s/kwe /fZNLwBxQIUAjrIYly8gFkzHNN/pfejM37g45fxWgsO3UuFS7f ZBzwtOYH6ySsv0idzKiig== Cc: lprosee@gmail.com, mext@ietf.org Subject: Re: [MEXT] why having DHCP do DNS resolution? (was: FW: Summary for the changes in hiopt-13) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Alex, Not that I think it is a requirement for this I-D to progress, but note that both WiMAX and 3GPP2 refer to this specification. Alper > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Tuesday, May 13, 2008 12:58 PM > To: Alper Yegin > Cc: heejin.jang@samsung.com; lprosee@gmail.com; mext@ietf.org > Subject: Re: [MEXT] why having DHCP do DNS resolution? (was: FW: Summary > for the changes in hiopt-13) > > Alper - for my clarification about procedure: has hiopt been implemented > or prototyped or demoed somehow? > > It's not my intention to write a thread holding up this I-D. > > Alex > > Alper Yegin wrote: > > Alex, > > > > Roaming is described where NAI is defined -- RFC 4282. > > > > If you see issues let us know. Otherwise let's try to wrap this up. Your > > thread seems to be the only one holding up this I-D. > > > > Thank you for your cooperation. > > > > Alper > > > >> -----Original Message----- > >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > >> Sent: Friday, May 09, 2008 11:11 PM > >> To: Alper Yegin > >> Cc: heejin.jang@samsung.com; lprosee@gmail.com; mext@ietf.org > >> Subject: Re: [MEXT] why having DHCP do DNS resolution? (was: FW: > Summary > >> for the changes in hiopt-13) > >> > >> Alper Yegin wrote: > >>> Hi Alex, > >>> > >>> The issue at hand is roaming, and identification of realm (as opposed > to > >>> identification of the host). That's what the realm portion of the NAI > is > >> for > >>> (in other IETF specs), and that's how it is also used in this spec as > >> well. > >>> I hope this clarifies. > >> Alper - what is 'roaming'? > >> > >> Alex > >> > >>> Alper > >>> Samsung > >>> > >>>> -----Original Message----- > >>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf > Of > >>>> Alexandru Petrescu > >>>> Sent: Wednesday, April 30, 2008 12:41 PM > >>>> To: heejin.jang@samsung.com > >>>> Cc: lprosee@gmail.com; mext@ietf.org > >>>> Subject: Re: [MEXT] why having DHCP do DNS resolution? (was: FW: > >> Summary > >>>> for the changes in hiopt-13) > >>>> > >>>> Heejin Jang wrote: > >>>>> Hi, Alex. See below. > >>>>> > >>>>> ps> I'm supposed to have a vacation till next Monday, and cannot > >>>>> access my samsung account. So kindly refer my gmail account as well. > >>>> Heejin, enjoy vacations :-) when back in office see below. > >>>> > >>>> [...] > >>>>>> Then I don't see why stateless DHCPv6 is needed for this? Plain > >>>>>> full DHCPv6 can accommodate this scenario. > >>>>> Basically plain (stateful) DHCPv6 is used for address configuration > >>>>> while stateless DHCPv6 is for other parameters configuration such as > >>>>> DNS server address. So this HN information should be delivered > >>>>> through stateless DHCPv6. > >>>> Let's clarify this use of Stateless DHCPv6 RFC3736. > >>>> > >>>> Why does a hiopt MN need to include a Home Network Identifier > >>>> (Sub-Opt-Code 1, eg realm of NAI) in the Home Network Information > >> Option > >>>> in the Information-Request? Why isn't it sufficient to use the > Client > >>>> Identifier Option DUID section 22.2 of RFC 3315 DHCPv6. > >>>> > >>>> Why isn't the DUID enough to identify the Client (1 - Link-layer > >> address > >>>> plus time, 2 - vendor-assigned unique id based on enterprise number, > 3 > >> - > >>>> link-layer address). > >>>> > >>>> Why is it thought that it is necessary to specify Home Network > >>>> Identifier Sub-Opt-Code 1 as being, for example, the realm part of a > >>>> NAI, when the DUID exists, is used and covers a different range of > >> cases. > >>>>>>>> I think that RFC doesn't suggest the Client to put data in a > >>>>>>>> request and the Server to suggest back a different data. Or, > >>>>>>>> apparently, a hiopt-13 Client puts IPv6 home network prefix in > >>>>>>>> a Request, with sub-opt-code equal 2, Relay forwards it to > >>>>>>>> Server, and Server puts another IPv6 home network prefix in a > >>>>>>>> Reply, apparently. Is this the intended hiop-13 behaviour? > >>>>>>>> > >>>>>>>> Is this behaviour in this sense completely different than the > >>>>>>>> typical > >>>>>>>> > >>>>>>>> DHCPv6 operation? > >>>>>>> Section 3.3 says > >>>>>>> > >>>>>>> " While the Sub-opt-code 1 is only available in both the > >>>>>>> requesting and the returned Home Network Information options, > >>>>>>> Sub-opt-codes 2, 3, 4, and 5 are available only in the returned > >>>>>>> Home Network Information option and the MIP6 Relay Agent option." > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Section 4.1 says > >>>>>>> > >>>>>>> " A value of 1 is the only Sub-opt-code available in the > >>>>>>> request." > >>>> Right, now makes better sense. For easing my humble reading this > >>>> statement could appear in section 3.1 where the message encoding of > >> Home > >>>> Network Information Option is described. > >>>> > >>>>>>> An MN cannot carry sub-opt-codes other than 1. This means that a > >>>>>>> sub-option in the request is used only to carry the MN's > >>>>>>> prefered target MSP in case of id-type 1 so that the server can > >>>>>>> reply the matching HA information. > >>>>>>> > >>>>>>> So, the server never replys with "the different" data. > >>>>>> Right, thanks, now I understand it better as being the basic hiopt > >>>>>> behaviour. > >>>>>> > >>>>>> Let me agree with you for a short while that it's good to identify > >>>>>> the subnet by a FQDN. > >>>>>> > >>>>>> If so basically MN (DHCP Client) puts FQDN in the request and the > >>>>>> DHCP Server sends back an IP address of the Home Agent. > >>>>>> > >>>>>> How is this different than DNS Resolution? Why do we need DHCP to > >>>>>> do DNS Resolution? > >>>>> While MNs are required to know an exact FQDN of the target (HA) for > >>>>> DNS resolution, DHCP discovery enables HA discovery in variable ways > >>>>> even in case MN does not have exact information about its home > >>>>> network. For e.g. it can request the local HAs with the id-type 0. > Or > >>>>> the server may return partially matching HA information as > described > >>>>> in Section 4.3. > >>>> I agree at high level but not in detail. > >>>> > >>>> The really big problem here - and in all bootstrapping documents - is > >>>> that we have not precisely described what is the information > available > >>>> at the MN prior to bootstrapping phase. Different documents make > >>>> different assumptions and they overlap. > >>>> > >>>> [skipped some for focusing the discussion] > >>>> > >>>>> IMHO, such a load-balancing approach is wellknown and does not need > >>>>> to be limited to VPN. Anyway here the key point is "to provide HA > >>>>> information based on NAI" can be implemented in various ways as > least > >>>>> by using 1) and 2) as described in previous mails. > >>>> If it is the key point then it should be much more clear than that. > >>>> It is far from being clear. Now here it's said "NAI" but in the > >>>> document it's said "for example, the realm part of NAI". If we > decide > >>>> to do only NAI-based HA address bootstrapping with DHCPv6 then I can > >>>> agree we can have a better document. > >>>> > >>>> That is a big if. > >>>> > >>>> Because - does DHCPv6 or DHCPv4 ever use NAI for address allocation > or > >>>> parameter configuration? I don't think so. They use MAC address (or > >>>> DUID) but not NAI. I find hiopt very much different than DHCPv6 in > >> this > >>>> sense. IMHO. ?. > >>>> > >>>> If one wants to use NAI (or its realm part) to find the corresponding > >> IP > >>>> address then use DNS straight resolution, not DHCP. > >>>> > >>>> Alex > >>>> > >>>> > >>>> > ______________________________________________________________________ > >>>> This email has been scanned by the MessageLabs Email Security System. > >>>> For more information please visit http://www.messagelabs.com/email > >>>> > ______________________________________________________________________ > >>>> _______________________________________________ > >>>> MEXT mailing list > >>>> MEXT@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mext > >>> > >> > >> ______________________________________________________________________ > >> This email has been scanned by the MessageLabs Email Security System. > >> For more information please visit http://www.messagelabs.com/email > >> ______________________________________________________________________ > > > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue May 13 04:51:09 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 632113A6C2A; Tue, 13 May 2008 04:51:09 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24B193A6C2A for ; Tue, 13 May 2008 04:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7l8-k8bwDNj for ; Tue, 13 May 2008 04:51:01 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.245.51]) by core3.amsl.com (Postfix) with SMTP id B9EB33A6C12 for ; Tue, 13 May 2008 04:51:00 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-119.messagelabs.com!1210679357!22430081!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 5631 invoked from network); 13 May 2008 11:49:17 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-11.tower-119.messagelabs.com with SMTP; 13 May 2008 11:49:17 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id m4DBnCYq004369; Tue, 13 May 2008 04:49:12 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id m4DBnB2J009043; Tue, 13 May 2008 06:49:11 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id m4DBn80M009031; Tue, 13 May 2008 06:49:09 -0500 (CDT) Message-ID: <48298034.3010201@gmail.com> Date: Tue, 13 May 2008 13:49:08 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Alper Yegin References: <0MKpCa-1JvskJ2w8j-0003SQ@mrelay.perfora.net> In-Reply-To: <0MKpCa-1JvskJ2w8j-0003SQ@mrelay.perfora.net> X-Antivirus: avast! (VPS 080512-0, 12/05/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: lprosee@gmail.com, mext@ietf.org Subject: Re: [MEXT] why having DHCP do DNS resolution? (was: FW: Summary for the changes in hiopt-13) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Alper Yegin wrote: > Alex, > > Not that I think it is a requirement for this I-D to progress, but > note that both WiMAX and 3GPP2 refer to this specification. Alper - thanks for the clarification. Then the other question deserves commenting: what is the IPR context for this specification? Alex > > Alper > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Tuesday, May 13, 2008 >> 12:58 PM To: Alper Yegin Cc: heejin.jang@samsung.com; >> lprosee@gmail.com; mext@ietf.org Subject: Re: [MEXT] why having >> DHCP do DNS resolution? (was: FW: Summary for the changes in >> hiopt-13) >> >> Alper - for my clarification about procedure: has hiopt been >> implemented or prototyped or demoed somehow? >> >> It's not my intention to write a thread holding up this I-D. >> >> Alex >> >> Alper Yegin wrote: >>> Alex, >>> >>> Roaming is described where NAI is defined -- RFC 4282. >>> >>> If you see issues let us know. Otherwise let's try to wrap this >>> up. Your thread seems to be the only one holding up this I-D. >>> >>> Thank you for your cooperation. >>> >>> Alper >>> >>>> -----Original Message----- From: Alexandru Petrescu >>>> [mailto:alexandru.petrescu@gmail.com] Sent: Friday, May 09, >>>> 2008 11:11 PM To: Alper Yegin Cc: heejin.jang@samsung.com; >>>> lprosee@gmail.com; mext@ietf.org Subject: Re: [MEXT] why having >>>> DHCP do DNS resolution? (was: FW: >> Summary >>>> for the changes in hiopt-13) >>>> >>>> Alper Yegin wrote: >>>>> Hi Alex, >>>>> >>>>> The issue at hand is roaming, and identification of realm (as >>>>> opposed >> to >>>>> identification of the host). That's what the realm portion of >>>>> the NAI >> is >>>> for >>>>> (in other IETF specs), and that's how it is also used in this >>>>> spec as >>>> well. >>>>> I hope this clarifies. >>>> Alper - what is 'roaming'? >>>> >>>> Alex >>>> >>>>> Alper Samsung >>>>> >>>>>> -----Original Message----- From: mext-bounces@ietf.org >>>>>> [mailto:mext-bounces@ietf.org] On Behalf >> Of >>>>>> Alexandru Petrescu Sent: Wednesday, April 30, 2008 12:41 PM >>>>>> To: heejin.jang@samsung.com Cc: lprosee@gmail.com; >>>>>> mext@ietf.org Subject: Re: [MEXT] why having DHCP do DNS >>>>>> resolution? (was: FW: >>>> Summary >>>>>> for the changes in hiopt-13) >>>>>> >>>>>> Heejin Jang wrote: >>>>>>> Hi, Alex. See below. >>>>>>> >>>>>>> ps> I'm supposed to have a vacation till next Monday, and >>>>>>> cannot access my samsung account. So kindly refer my >>>>>>> gmail account as well. >>>>>> Heejin, enjoy vacations :-) when back in office see below. >>>>>> >>>>>> >>>>>> [...] >>>>>>>> Then I don't see why stateless DHCPv6 is needed for >>>>>>>> this? Plain full DHCPv6 can accommodate this scenario. >>>>>>>> >>>>>>> Basically plain (stateful) DHCPv6 is used for address >>>>>>> configuration while stateless DHCPv6 is for other >>>>>>> parameters configuration such as DNS server address. So >>>>>>> this HN information should be delivered through stateless >>>>>>> DHCPv6. >>>>>> Let's clarify this use of Stateless DHCPv6 RFC3736. >>>>>> >>>>>> Why does a hiopt MN need to include a Home Network >>>>>> Identifier (Sub-Opt-Code 1, eg realm of NAI) in the Home >>>>>> Network Information >>>> Option >>>>>> in the Information-Request? Why isn't it sufficient to use >>>>>> the >> Client >>>>>> Identifier Option DUID section 22.2 of RFC 3315 DHCPv6. >>>>>> >>>>>> Why isn't the DUID enough to identify the Client (1 - >>>>>> Link-layer >>>> address >>>>>> plus time, 2 - vendor-assigned unique id based on >>>>>> enterprise number, >> 3 >>>> - >>>>>> link-layer address). >>>>>> >>>>>> Why is it thought that it is necessary to specify Home >>>>>> Network Identifier Sub-Opt-Code 1 as being, for example, >>>>>> the realm part of a NAI, when the DUID exists, is used and >>>>>> covers a different range of >>>> cases. >>>>>>>>>> I think that RFC doesn't suggest the Client to put >>>>>>>>>> data in a request and the Server to suggest back a >>>>>>>>>> different data. Or, apparently, a hiopt-13 Client >>>>>>>>>> puts IPv6 home network prefix in a Request, with >>>>>>>>>> sub-opt-code equal 2, Relay forwards it to Server, >>>>>>>>>> and Server puts another IPv6 home network prefix in >>>>>>>>>> a Reply, apparently. Is this the intended hiop-13 >>>>>>>>>> behaviour? >>>>>>>>>> >>>>>>>>>> Is this behaviour in this sense completely >>>>>>>>>> different than the typical >>>>>>>>>> >>>>>>>>>> DHCPv6 operation? >>>>>>>>> Section 3.3 says >>>>>>>>> >>>>>>>>> " While the Sub-opt-code 1 is only available in both >>>>>>>>> the requesting and the returned Home Network >>>>>>>>> Information options, Sub-opt-codes 2, 3, 4, and 5 are >>>>>>>>> available only in the returned Home Network >>>>>>>>> Information option and the MIP6 Relay Agent option." >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Section 4.1 says >>>>>>>>> >>>>>>>>> " A value of 1 is the only Sub-opt-code available in >>>>>>>>> the request." >>>>>> Right, now makes better sense. For easing my humble >>>>>> reading this statement could appear in section 3.1 where >>>>>> the message encoding of >>>> Home >>>>>> Network Information Option is described. >>>>>> >>>>>>>>> An MN cannot carry sub-opt-codes other than 1. This >>>>>>>>> means that a sub-option in the request is used only >>>>>>>>> to carry the MN's prefered target MSP in case of >>>>>>>>> id-type 1 so that the server can reply the matching >>>>>>>>> HA information. >>>>>>>>> >>>>>>>>> So, the server never replys with "the different" >>>>>>>>> data. >>>>>>>> Right, thanks, now I understand it better as being the >>>>>>>> basic hiopt behaviour. >>>>>>>> >>>>>>>> Let me agree with you for a short while that it's good >>>>>>>> to identify the subnet by a FQDN. >>>>>>>> >>>>>>>> If so basically MN (DHCP Client) puts FQDN in the >>>>>>>> request and the DHCP Server sends back an IP address of >>>>>>>> the Home Agent. >>>>>>>> >>>>>>>> How is this different than DNS Resolution? Why do we >>>>>>>> need DHCP to do DNS Resolution? >>>>>>> While MNs are required to know an exact FQDN of the >>>>>>> target (HA) for DNS resolution, DHCP discovery enables HA >>>>>>> discovery in variable ways even in case MN does not have >>>>>>> exact information about its home network. For e.g. it can >>>>>>> request the local HAs with the id-type 0. >> Or >>>>>>> the server may return partially matching HA information >>>>>>> as >> described >>>>>>> in Section 4.3. >>>>>> I agree at high level but not in detail. >>>>>> >>>>>> The really big problem here - and in all bootstrapping >>>>>> documents - is that we have not precisely described what is >>>>>> the information >> available >>>>>> at the MN prior to bootstrapping phase. Different >>>>>> documents make different assumptions and they overlap. >>>>>> >>>>>> [skipped some for focusing the discussion] >>>>>> >>>>>>> IMHO, such a load-balancing approach is wellknown and >>>>>>> does not need to be limited to VPN. Anyway here the key >>>>>>> point is "to provide HA information based on NAI" can be >>>>>>> implemented in various ways as >> least >>>>>>> by using 1) and 2) as described in previous mails. >>>>>> If it is the key point then it should be much more clear >>>>>> than that. It is far from being clear. Now here it's said >>>>>> "NAI" but in the document it's said "for example, the realm >>>>>> part of NAI". If we >> decide >>>>>> to do only NAI-based HA address bootstrapping with DHCPv6 >>>>>> then I can agree we can have a better document. >>>>>> >>>>>> That is a big if. >>>>>> >>>>>> Because - does DHCPv6 or DHCPv4 ever use NAI for address >>>>>> allocation >> or >>>>>> parameter configuration? I don't think so. They use MAC >>>>>> address (or DUID) but not NAI. I find hiopt very much >>>>>> different than DHCPv6 in >>>> this >>>>>> sense. IMHO. ?. >>>>>> >>>>>> If one wants to use NAI (or its realm part) to find the >>>>>> corresponding >>>> IP >>>>>> address then use DNS straight resolution, not DHCP. >>>>>> >>>>>> Alex >>>>>> >>>>>> >>>>>> >> ______________________________________________________________________ >> >>>>>> This email has been scanned by the MessageLabs Email >>>>>> Security System. For more information please visit >>>>>> http://www.messagelabs.com/email >>>>>> >> ______________________________________________________________________ >> >>>>>> _______________________________________________ MEXT >>>>>> mailing list MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>> ______________________________________________________________________ >>>> This email has been scanned by the MessageLabs Email Security >>>> System. For more information please visit >>>> http://www.messagelabs.com/email >>>> ______________________________________________________________________ >>>> >>> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security >> System. For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue May 13 06:09:27 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8545E3A6C03; Tue, 13 May 2008 06:09:27 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E451C3A6C03 for ; Tue, 13 May 2008 06:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOzp-88CqwTI for ; Tue, 13 May 2008 06:09:23 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id F341C28C2D6 for ; Tue, 13 May 2008 06:09:22 -0700 (PDT) Received: from IBM52A5038A94F (dsl88-247-34287.ttnet.net.tr [88.247.133.239]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1JvtlB14Vo-0003bV; Tue, 13 May 2008 08:37:46 -0400 From: "Alper Yegin" To: "'Alexandru Petrescu'" Date: Tue, 13 May 2008 15:37:11 +0300 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: <48298034.3010201@gmail.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: Aci072ca4cAXCoXCTzCboDc0kBkNRgABnM6Q Message-Id: <0MKpCa-1JvtlB14Vo-0003bV@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/b37Md0g8JKk8cbgs7yAHrh13e6XIfV4rB8un qFbd9gvRvPhyEL6+q0Th4r9SeWI4QBfcWWTCJw9SGYON8vqM6h dN6p6vYMiPs300hTmUX5A== Cc: lprosee@gmail.com, mext@ietf.org Subject: Re: [MEXT] why having DHCP do DNS resolution? (was: FW: Summary for the changes in hiopt-13) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I can only answer this for myself. I am not aware of any IPRs on this I-D. Alper Samsung > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Tuesday, May 13, 2008 2:49 PM > To: Alper Yegin > Cc: heejin.jang@samsung.com; lprosee@gmail.com; mext@ietf.org > Subject: Re: [MEXT] why having DHCP do DNS resolution? (was: FW: Summary > for the changes in hiopt-13) > > Alper Yegin wrote: > > Alex, > > > > Not that I think it is a requirement for this I-D to progress, but > > note that both WiMAX and 3GPP2 refer to this specification. > > Alper - thanks for the clarification. Then the other question deserves > commenting: what is the IPR context for this specification? > > Alex > > > > > Alper > > > >> -----Original Message----- From: Alexandru Petrescu > >> [mailto:alexandru.petrescu@gmail.com] Sent: Tuesday, May 13, 2008 > >> 12:58 PM To: Alper Yegin Cc: heejin.jang@samsung.com; > >> lprosee@gmail.com; mext@ietf.org Subject: Re: [MEXT] why having > >> DHCP do DNS resolution? (was: FW: Summary for the changes in > >> hiopt-13) > >> > >> Alper - for my clarification about procedure: has hiopt been > >> implemented or prototyped or demoed somehow? > >> > >> It's not my intention to write a thread holding up this I-D. > >> > >> Alex > >> > >> Alper Yegin wrote: > >>> Alex, > >>> > >>> Roaming is described where NAI is defined -- RFC 4282. > >>> > >>> If you see issues let us know. Otherwise let's try to wrap this > >>> up. Your thread seems to be the only one holding up this I-D. > >>> > >>> Thank you for your cooperation. > >>> > >>> Alper > >>> > >>>> -----Original Message----- From: Alexandru Petrescu > >>>> [mailto:alexandru.petrescu@gmail.com] Sent: Friday, May 09, > >>>> 2008 11:11 PM To: Alper Yegin Cc: heejin.jang@samsung.com; > >>>> lprosee@gmail.com; mext@ietf.org Subject: Re: [MEXT] why having > >>>> DHCP do DNS resolution? (was: FW: > >> Summary > >>>> for the changes in hiopt-13) > >>>> > >>>> Alper Yegin wrote: > >>>>> Hi Alex, > >>>>> > >>>>> The issue at hand is roaming, and identification of realm (as > >>>>> opposed > >> to > >>>>> identification of the host). That's what the realm portion of > >>>>> the NAI > >> is > >>>> for > >>>>> (in other IETF specs), and that's how it is also used in this > >>>>> spec as > >>>> well. > >>>>> I hope this clarifies. > >>>> Alper - what is 'roaming'? > >>>> > >>>> Alex > >>>> > >>>>> Alper Samsung > >>>>> > >>>>>> -----Original Message----- From: mext-bounces@ietf.org > >>>>>> [mailto:mext-bounces@ietf.org] On Behalf > >> Of > >>>>>> Alexandru Petrescu Sent: Wednesday, April 30, 2008 12:41 PM > >>>>>> To: heejin.jang@samsung.com Cc: lprosee@gmail.com; > >>>>>> mext@ietf.org Subject: Re: [MEXT] why having DHCP do DNS > >>>>>> resolution? (was: FW: > >>>> Summary > >>>>>> for the changes in hiopt-13) > >>>>>> > >>>>>> Heejin Jang wrote: > >>>>>>> Hi, Alex. See below. > >>>>>>> > >>>>>>> ps> I'm supposed to have a vacation till next Monday, and > >>>>>>> cannot access my samsung account. So kindly refer my > >>>>>>> gmail account as well. > >>>>>> Heejin, enjoy vacations :-) when back in office see below. > >>>>>> > >>>>>> > >>>>>> [...] > >>>>>>>> Then I don't see why stateless DHCPv6 is needed for > >>>>>>>> this? Plain full DHCPv6 can accommodate this scenario. > >>>>>>>> > >>>>>>> Basically plain (stateful) DHCPv6 is used for address > >>>>>>> configuration while stateless DHCPv6 is for other > >>>>>>> parameters configuration such as DNS server address. So > >>>>>>> this HN information should be delivered through stateless > >>>>>>> DHCPv6. > >>>>>> Let's clarify this use of Stateless DHCPv6 RFC3736. > >>>>>> > >>>>>> Why does a hiopt MN need to include a Home Network > >>>>>> Identifier (Sub-Opt-Code 1, eg realm of NAI) in the Home > >>>>>> Network Information > >>>> Option > >>>>>> in the Information-Request? Why isn't it sufficient to use > >>>>>> the > >> Client > >>>>>> Identifier Option DUID section 22.2 of RFC 3315 DHCPv6. > >>>>>> > >>>>>> Why isn't the DUID enough to identify the Client (1 - > >>>>>> Link-layer > >>>> address > >>>>>> plus time, 2 - vendor-assigned unique id based on > >>>>>> enterprise number, > >> 3 > >>>> - > >>>>>> link-layer address). > >>>>>> > >>>>>> Why is it thought that it is necessary to specify Home > >>>>>> Network Identifier Sub-Opt-Code 1 as being, for example, > >>>>>> the realm part of a NAI, when the DUID exists, is used and > >>>>>> covers a different range of > >>>> cases. > >>>>>>>>>> I think that RFC doesn't suggest the Client to put > >>>>>>>>>> data in a request and the Server to suggest back a > >>>>>>>>>> different data. Or, apparently, a hiopt-13 Client > >>>>>>>>>> puts IPv6 home network prefix in a Request, with > >>>>>>>>>> sub-opt-code equal 2, Relay forwards it to Server, > >>>>>>>>>> and Server puts another IPv6 home network prefix in > >>>>>>>>>> a Reply, apparently. Is this the intended hiop-13 > >>>>>>>>>> behaviour? > >>>>>>>>>> > >>>>>>>>>> Is this behaviour in this sense completely > >>>>>>>>>> different than the typical > >>>>>>>>>> > >>>>>>>>>> DHCPv6 operation? > >>>>>>>>> Section 3.3 says > >>>>>>>>> > >>>>>>>>> " While the Sub-opt-code 1 is only available in both > >>>>>>>>> the requesting and the returned Home Network > >>>>>>>>> Information options, Sub-opt-codes 2, 3, 4, and 5 are > >>>>>>>>> available only in the returned Home Network > >>>>>>>>> Information option and the MIP6 Relay Agent option." > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Section 4.1 says > >>>>>>>>> > >>>>>>>>> " A value of 1 is the only Sub-opt-code available in > >>>>>>>>> the request." > >>>>>> Right, now makes better sense. For easing my humble > >>>>>> reading this statement could appear in section 3.1 where > >>>>>> the message encoding of > >>>> Home > >>>>>> Network Information Option is described. > >>>>>> > >>>>>>>>> An MN cannot carry sub-opt-codes other than 1. This > >>>>>>>>> means that a sub-option in the request is used only > >>>>>>>>> to carry the MN's prefered target MSP in case of > >>>>>>>>> id-type 1 so that the server can reply the matching > >>>>>>>>> HA information. > >>>>>>>>> > >>>>>>>>> So, the server never replys with "the different" > >>>>>>>>> data. > >>>>>>>> Right, thanks, now I understand it better as being the > >>>>>>>> basic hiopt behaviour. > >>>>>>>> > >>>>>>>> Let me agree with you for a short while that it's good > >>>>>>>> to identify the subnet by a FQDN. > >>>>>>>> > >>>>>>>> If so basically MN (DHCP Client) puts FQDN in the > >>>>>>>> request and the DHCP Server sends back an IP address of > >>>>>>>> the Home Agent. > >>>>>>>> > >>>>>>>> How is this different than DNS Resolution? Why do we > >>>>>>>> need DHCP to do DNS Resolution? > >>>>>>> While MNs are required to know an exact FQDN of the > >>>>>>> target (HA) for DNS resolution, DHCP discovery enables HA > >>>>>>> discovery in variable ways even in case MN does not have > >>>>>>> exact information about its home network. For e.g. it can > >>>>>>> request the local HAs with the id-type 0. > >> Or > >>>>>>> the server may return partially matching HA information > >>>>>>> as > >> described > >>>>>>> in Section 4.3. > >>>>>> I agree at high level but not in detail. > >>>>>> > >>>>>> The really big problem here - and in all bootstrapping > >>>>>> documents - is that we have not precisely described what is > >>>>>> the information > >> available > >>>>>> at the MN prior to bootstrapping phase. Different > >>>>>> documents make different assumptions and they overlap. > >>>>>> > >>>>>> [skipped some for focusing the discussion] > >>>>>> > >>>>>>> IMHO, such a load-balancing approach is wellknown and > >>>>>>> does not need to be limited to VPN. Anyway here the key > >>>>>>> point is "to provide HA information based on NAI" can be > >>>>>>> implemented in various ways as > >> least > >>>>>>> by using 1) and 2) as described in previous mails. > >>>>>> If it is the key point then it should be much more clear > >>>>>> than that. It is far from being clear. Now here it's said > >>>>>> "NAI" but in the document it's said "for example, the realm > >>>>>> part of NAI". If we > >> decide > >>>>>> to do only NAI-based HA address bootstrapping with DHCPv6 > >>>>>> then I can agree we can have a better document. > >>>>>> > >>>>>> That is a big if. > >>>>>> > >>>>>> Because - does DHCPv6 or DHCPv4 ever use NAI for address > >>>>>> allocation > >> or > >>>>>> parameter configuration? I don't think so. They use MAC > >>>>>> address (or DUID) but not NAI. I find hiopt very much > >>>>>> different than DHCPv6 in > >>>> this > >>>>>> sense. IMHO. ?. > >>>>>> > >>>>>> If one wants to use NAI (or its realm part) to find the > >>>>>> corresponding > >>>> IP > >>>>>> address then use DNS straight resolution, not DHCP. > >>>>>> > >>>>>> Alex > >>>>>> > >>>>>> > >>>>>> > >> ______________________________________________________________________ > >> > >>>>>> This email has been scanned by the MessageLabs Email > >>>>>> Security System. For more information please visit > >>>>>> http://www.messagelabs.com/email > >>>>>> > >> ______________________________________________________________________ > >> > >>>>>> _______________________________________________ MEXT > >>>>>> mailing list MEXT@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mext > >>>> > ______________________________________________________________________ > >>>> This email has been scanned by the MessageLabs Email Security > >>>> System. For more information please visit > >>>> http://www.messagelabs.com/email > >>>> > ______________________________________________________________________ > >>>> > >>> > >> > >> ______________________________________________________________________ > >> This email has been scanned by the MessageLabs Email Security > >> System. For more information please visit > >> http://www.messagelabs.com/email > >> ______________________________________________________________________ > >> > > > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue May 13 07:24:07 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3EF53A67F7; Tue, 13 May 2008 07:24:07 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6359E3A65A6 for ; Tue, 13 May 2008 07:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3Mcj8RqRc1e for ; Tue, 13 May 2008 07:24:01 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id C06573A67F7 for ; Tue, 13 May 2008 07:24:01 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-128.messagelabs.com!1210688120!5965904!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 21628 invoked from network); 13 May 2008 14:15:20 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-128.messagelabs.com with SMTP; 13 May 2008 14:15:20 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m4DEFF9N017293; Tue, 13 May 2008 07:15:15 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id m4DEFEcL001282; Tue, 13 May 2008 09:15:15 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id m4DEFD4H001260; Tue, 13 May 2008 09:15:13 -0500 (CDT) Message-ID: <4829A270.4060705@gmail.com> Date: Tue, 13 May 2008 16:15:12 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Alper Yegin References: <0MKpCa-1JvtlB14Vo-0003bV@mrelay.perfora.net> In-Reply-To: <0MKpCa-1JvtlB14Vo-0003bV@mrelay.perfora.net> X-Antivirus: avast! (VPS 080512-0, 12/05/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: lprosee@gmail.com, mext@ietf.org Subject: Re: [MEXT] why having DHCP do DNS resolution? (was: FW: Summary for the changes in hiopt-13) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Alper Yegin wrote: > I can only answer this for myself. I am not aware of any IPRs on this > I-D. Alper - thanks for the clarifications. Let me summarize: one thinks there's no IPR on the doc, the document was not prototyped/implemented, the document is being referred by 3GPP2 and by WiMax, and technically there appears to be some miscomprehension from me about the use of NAI to discover a HA with DHCP (as opposed to using a DUID). In this context, do you think the document should be progressed on the Standards Track? In my experience, I recognize this situation as a typical situation which would progress a draft on the Informational track. I hope this clarifies my part of it. I will let other WG members express about the hiopt situation - what do other people think? Alex > > Alper Samsung > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Tuesday, May 13, 2008 >> 2:49 PM To: Alper Yegin Cc: heejin.jang@samsung.com; >> lprosee@gmail.com; mext@ietf.org Subject: Re: [MEXT] why having >> DHCP do DNS resolution? (was: FW: Summary for the changes in >> hiopt-13) >> >> Alper Yegin wrote: >>> Alex, >>> >>> Not that I think it is a requirement for this I-D to progress, >>> but note that both WiMAX and 3GPP2 refer to this specification. >> Alper - thanks for the clarification. Then the other question >> deserves commenting: what is the IPR context for this >> specification? >> >> Alex >> >>> Alper >>> >>>> -----Original Message----- From: Alexandru Petrescu >>>> [mailto:alexandru.petrescu@gmail.com] Sent: Tuesday, May 13, >>>> 2008 12:58 PM To: Alper Yegin Cc: heejin.jang@samsung.com; >>>> lprosee@gmail.com; mext@ietf.org Subject: Re: [MEXT] why having >>>> DHCP do DNS resolution? (was: FW: Summary for the changes in >>>> hiopt-13) >>>> >>>> Alper - for my clarification about procedure: has hiopt been >>>> implemented or prototyped or demoed somehow? >>>> >>>> It's not my intention to write a thread holding up this I-D. >>>> >>>> Alex >>>> >>>> Alper Yegin wrote: >>>>> Alex, >>>>> >>>>> Roaming is described where NAI is defined -- RFC 4282. >>>>> >>>>> If you see issues let us know. Otherwise let's try to wrap >>>>> this up. Your thread seems to be the only one holding up this >>>>> I-D. >>>>> >>>>> Thank you for your cooperation. >>>>> >>>>> Alper >>>>> >>>>>> -----Original Message----- From: Alexandru Petrescu >>>>>> [mailto:alexandru.petrescu@gmail.com] Sent: Friday, May 09, >>>>>> 2008 11:11 PM To: Alper Yegin Cc: heejin.jang@samsung.com; >>>>>> lprosee@gmail.com; mext@ietf.org Subject: Re: [MEXT] why >>>>>> having DHCP do DNS resolution? (was: FW: >>>> Summary >>>>>> for the changes in hiopt-13) >>>>>> >>>>>> Alper Yegin wrote: >>>>>>> Hi Alex, >>>>>>> >>>>>>> The issue at hand is roaming, and identification of realm >>>>>>> (as opposed >>>> to >>>>>>> identification of the host). That's what the realm >>>>>>> portion of the NAI >>>> is >>>>>> for >>>>>>> (in other IETF specs), and that's how it is also used in >>>>>>> this spec as >>>>>> well. >>>>>>> I hope this clarifies. >>>>>> Alper - what is 'roaming'? >>>>>> >>>>>> Alex >>>>>> >>>>>>> Alper Samsung >>>>>>> >>>>>>>> -----Original Message----- From: mext-bounces@ietf.org >>>>>>>> [mailto:mext-bounces@ietf.org] On Behalf >>>> Of >>>>>>>> Alexandru Petrescu Sent: Wednesday, April 30, 2008 >>>>>>>> 12:41 PM To: heejin.jang@samsung.com Cc: >>>>>>>> lprosee@gmail.com; mext@ietf.org Subject: Re: [MEXT] >>>>>>>> why having DHCP do DNS resolution? (was: FW: >>>>>> Summary >>>>>>>> for the changes in hiopt-13) >>>>>>>> >>>>>>>> Heejin Jang wrote: >>>>>>>>> Hi, Alex. See below. >>>>>>>>> >>>>>>>>> ps> I'm supposed to have a vacation till next Monday, >>>>>>>>> and cannot access my samsung account. So kindly >>>>>>>>> refer my gmail account as well. >>>>>>>> Heejin, enjoy vacations :-) when back in office see >>>>>>>> below. >>>>>>>> >>>>>>>> >>>>>>>> [...] >>>>>>>>>> Then I don't see why stateless DHCPv6 is needed for >>>>>>>>>> this? Plain full DHCPv6 can accommodate this >>>>>>>>>> scenario. >>>>>>>>>> >>>>>>>>> Basically plain (stateful) DHCPv6 is used for address >>>>>>>>> configuration while stateless DHCPv6 is for other >>>>>>>>> parameters configuration such as DNS server address. >>>>>>>>> So this HN information should be delivered through >>>>>>>>> stateless DHCPv6. >>>>>>>> Let's clarify this use of Stateless DHCPv6 RFC3736. >>>>>>>> >>>>>>>> Why does a hiopt MN need to include a Home Network >>>>>>>> Identifier (Sub-Opt-Code 1, eg realm of NAI) in the >>>>>>>> Home Network Information >>>>>> Option >>>>>>>> in the Information-Request? Why isn't it sufficient to >>>>>>>> use the >>>> Client >>>>>>>> Identifier Option DUID section 22.2 of RFC 3315 DHCPv6. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Why isn't the DUID enough to identify the Client (1 - >>>>>>>> Link-layer >>>>>> address >>>>>>>> plus time, 2 - vendor-assigned unique id based on >>>>>>>> enterprise number, >>>> 3 >>>>>> - >>>>>>>> link-layer address). >>>>>>>> >>>>>>>> Why is it thought that it is necessary to specify Home >>>>>>>> Network Identifier Sub-Opt-Code 1 as being, for >>>>>>>> example, the realm part of a NAI, when the DUID exists, >>>>>>>> is used and covers a different range of >>>>>> cases. >>>>>>>>>>>> I think that RFC doesn't suggest the Client to >>>>>>>>>>>> put data in a request and the Server to suggest >>>>>>>>>>>> back a different data. Or, apparently, a >>>>>>>>>>>> hiopt-13 Client puts IPv6 home network prefix >>>>>>>>>>>> in a Request, with sub-opt-code equal 2, Relay >>>>>>>>>>>> forwards it to Server, and Server puts another >>>>>>>>>>>> IPv6 home network prefix in a Reply, >>>>>>>>>>>> apparently. Is this the intended hiop-13 >>>>>>>>>>>> behaviour? >>>>>>>>>>>> >>>>>>>>>>>> Is this behaviour in this sense completely >>>>>>>>>>>> different than the typical >>>>>>>>>>>> >>>>>>>>>>>> DHCPv6 operation? >>>>>>>>>>> Section 3.3 says >>>>>>>>>>> >>>>>>>>>>> " While the Sub-opt-code 1 is only available in >>>>>>>>>>> both the requesting and the returned Home Network >>>>>>>>>>> Information options, Sub-opt-codes 2, 3, 4, and >>>>>>>>>>> 5 are available only in the returned Home Network >>>>>>>>>>> Information option and the MIP6 Relay Agent >>>>>>>>>>> option." >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Section 4.1 says >>>>>>>>>>> >>>>>>>>>>> " A value of 1 is the only Sub-opt-code >>>>>>>>>>> available in the request." >>>>>>>> Right, now makes better sense. For easing my humble >>>>>>>> reading this statement could appear in section 3.1 >>>>>>>> where the message encoding of >>>>>> Home >>>>>>>> Network Information Option is described. >>>>>>>> >>>>>>>>>>> An MN cannot carry sub-opt-codes other than 1. >>>>>>>>>>> This means that a sub-option in the request is >>>>>>>>>>> used only to carry the MN's prefered target MSP >>>>>>>>>>> in case of id-type 1 so that the server can reply >>>>>>>>>>> the matching HA information. >>>>>>>>>>> >>>>>>>>>>> So, the server never replys with "the different" >>>>>>>>>>> data. >>>>>>>>>> Right, thanks, now I understand it better as being >>>>>>>>>> the basic hiopt behaviour. >>>>>>>>>> >>>>>>>>>> Let me agree with you for a short while that it's >>>>>>>>>> good to identify the subnet by a FQDN. >>>>>>>>>> >>>>>>>>>> If so basically MN (DHCP Client) puts FQDN in the >>>>>>>>>> request and the DHCP Server sends back an IP >>>>>>>>>> address of the Home Agent. >>>>>>>>>> >>>>>>>>>> How is this different than DNS Resolution? Why do >>>>>>>>>> we need DHCP to do DNS Resolution? >>>>>>>>> While MNs are required to know an exact FQDN of the >>>>>>>>> target (HA) for DNS resolution, DHCP discovery >>>>>>>>> enables HA discovery in variable ways even in case MN >>>>>>>>> does not have exact information about its home >>>>>>>>> network. For e.g. it can request the local HAs with >>>>>>>>> the id-type 0. >>>> Or >>>>>>>>> the server may return partially matching HA >>>>>>>>> information as >>>> described >>>>>>>>> in Section 4.3. >>>>>>>> I agree at high level but not in detail. >>>>>>>> >>>>>>>> The really big problem here - and in all bootstrapping >>>>>>>> documents - is that we have not precisely described >>>>>>>> what is the information >>>> available >>>>>>>> at the MN prior to bootstrapping phase. Different >>>>>>>> documents make different assumptions and they overlap. >>>>>>>> >>>>>>>> [skipped some for focusing the discussion] >>>>>>>> >>>>>>>>> IMHO, such a load-balancing approach is wellknown and >>>>>>>>> does not need to be limited to VPN. Anyway here the >>>>>>>>> key point is "to provide HA information based on NAI" >>>>>>>>> can be implemented in various ways as >>>> least >>>>>>>>> by using 1) and 2) as described in previous mails. >>>>>>>> If it is the key point then it should be much more >>>>>>>> clear than that. It is far from being clear. Now here >>>>>>>> it's said "NAI" but in the document it's said "for >>>>>>>> example, the realm part of NAI". If we >>>> decide >>>>>>>> to do only NAI-based HA address bootstrapping with >>>>>>>> DHCPv6 then I can agree we can have a better document. >>>>>>>> >>>>>>>> That is a big if. >>>>>>>> >>>>>>>> Because - does DHCPv6 or DHCPv4 ever use NAI for >>>>>>>> address allocation >>>> or >>>>>>>> parameter configuration? I don't think so. They use >>>>>>>> MAC address (or DUID) but not NAI. I find hiopt very >>>>>>>> much different than DHCPv6 in >>>>>> this >>>>>>>> sense. IMHO. ?. >>>>>>>> >>>>>>>> If one wants to use NAI (or its realm part) to find the >>>>>>>> corresponding >>>>>> IP >>>>>>>> address then use DNS straight resolution, not DHCP. >>>>>>>> >>>>>>>> Alex >>>>>>>> >>>>>>>> >>>>>>>> >>>> ______________________________________________________________________ >>>> >>>> >>>> >>>>>>>> This email has been scanned by the MessageLabs Email >>>>>>>> Security System. For more information please visit >>>>>>>> http://www.messagelabs.com/email >>>>>>>> >>>> ______________________________________________________________________ >>>> >>>> >>>> >>>>>>>> _______________________________________________ MEXT >>>>>>>> mailing list MEXT@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mext >> ______________________________________________________________________ >> >> >>>>>> This email has been scanned by the MessageLabs Email >>>>>> Security System. For more information please visit >>>>>> http://www.messagelabs.com/email >>>>>> >> ______________________________________________________________________ >> >> >>>> ______________________________________________________________________ >>>> This email has been scanned by the MessageLabs Email Security >>>> System. For more information please visit >>>> http://www.messagelabs.com/email >>>> ______________________________________________________________________ >>>> >>>> >>>> >>> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security >> System. For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue May 13 07:31:46 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 369913A68B6; Tue, 13 May 2008 07:31:46 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C708C3A6BF4 for ; Tue, 13 May 2008 07:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIv7J7VOk6uX for ; Tue, 13 May 2008 07:31:43 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 947AE3A65A6 for ; Tue, 13 May 2008 07:31:42 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4DETVvo009876; Tue, 13 May 2008 17:29:32 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 17:29:26 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 09:29:23 -0500 Received: from 10.241.59.74 ([10.241.59.74]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Tue, 13 May 2008 14:29:23 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Tue, 13 May 2008 09:29:50 -0500 From: Basavaraj Patil To: ext Alexandru Petrescu , Alper Yegin Message-ID: Thread-Topic: [MEXT] why having DHCP do DNS resolution? (was: FW: Summary for the changes in hiopt-13) Thread-Index: Aci1Bc0RC+YbuiD5Ed21cwARJNUNiA== In-Reply-To: <4829A270.4060705@gmail.com> Mime-version: 1.0 X-OriginalArrivalTime: 13 May 2008 14:29:23.0735 (UTC) FILETIME=[BD69CA70:01C8B505] X-Nokia-AV: Clean Cc: lprosee@gmail.com, mext@ietf.org Subject: Re: [MEXT] why having DHCP do DNS resolution? (was: FW: Summary for the changes in hiopt-13) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Alex, There is no requirement for an I-D to have implementations in order for it to be progressed as a standards track RFC (Proposed standard). To get to draft standard, we need to show implementations (multiple) and also interop results. Use of DHCP (options) to obtain an HA address is a valid approach and hence I do not see any reason why this should be an informational document. The DHCP options being specified in this I-D IMO should be specified by the IETF as a proposed standard. -Raj On 5/13/08 9:15 AM, "ext Alexandru Petrescu" wrote: > Alper Yegin wrote: >> I can only answer this for myself. I am not aware of any IPRs on this >> I-D. > > Alper - thanks for the clarifications. > > Let me summarize: one thinks there's no IPR on the doc, the document > was not prototyped/implemented, the document is being referred by 3GPP2 > and by WiMax, and technically there appears to be some miscomprehension > from me about the use of NAI to discover a HA with DHCP (as opposed to > using a DUID). > > In this context, do you think the document should be progressed on the > Standards Track? > > In my experience, I recognize this situation as a typical situation > which would progress a draft on the Informational track. > > I hope this clarifies my part of it. I will let other WG members > express about the hiopt situation - what do other people think? > > Alex > >> >> Alper Samsung >> >>> -----Original Message----- From: Alexandru Petrescu >>> [mailto:alexandru.petrescu@gmail.com] Sent: Tuesday, May 13, 2008 >>> 2:49 PM To: Alper Yegin Cc: heejin.jang@samsung.com; >>> lprosee@gmail.com; mext@ietf.org Subject: Re: [MEXT] why having >>> DHCP do DNS resolution? (was: FW: Summary for the changes in >>> hiopt-13) >>> >>> Alper Yegin wrote: >>>> Alex, >>>> >>>> Not that I think it is a requirement for this I-D to progress, >>>> but note that both WiMAX and 3GPP2 refer to this specification. >>> Alper - thanks for the clarification. Then the other question >>> deserves commenting: what is the IPR context for this >>> specification? >>> >>> Alex >>> >>>> Alper >>>> >>>>> -----Original Message----- From: Alexandru Petrescu >>>>> [mailto:alexandru.petrescu@gmail.com] Sent: Tuesday, May 13, >>>>> 2008 12:58 PM To: Alper Yegin Cc: heejin.jang@samsung.com; >>>>> lprosee@gmail.com; mext@ietf.org Subject: Re: [MEXT] why having >>>>> DHCP do DNS resolution? (was: FW: Summary for the changes in >>>>> hiopt-13) >>>>> >>>>> Alper - for my clarification about procedure: has hiopt been >>>>> implemented or prototyped or demoed somehow? >>>>> >>>>> It's not my intention to write a thread holding up this I-D. >>>>> >>>>> Alex >>>>> >>>>> Alper Yegin wrote: >>>>>> Alex, >>>>>> >>>>>> Roaming is described where NAI is defined -- RFC 4282. >>>>>> >>>>>> If you see issues let us know. Otherwise let's try to wrap >>>>>> this up. Your thread seems to be the only one holding up this >>>>>> I-D. >>>>>> >>>>>> Thank you for your cooperation. >>>>>> >>>>>> Alper >>>>>> >>>>>>> -----Original Message----- From: Alexandru Petrescu >>>>>>> [mailto:alexandru.petrescu@gmail.com] Sent: Friday, May 09, >>>>>>> 2008 11:11 PM To: Alper Yegin Cc: heejin.jang@samsung.com; >>>>>>> lprosee@gmail.com; mext@ietf.org Subject: Re: [MEXT] why >>>>>>> having DHCP do DNS resolution? (was: FW: >>>>> Summary >>>>>>> for the changes in hiopt-13) >>>>>>> >>>>>>> Alper Yegin wrote: >>>>>>>> Hi Alex, >>>>>>>> >>>>>>>> The issue at hand is roaming, and identification of realm >>>>>>>> (as opposed >>>>> to >>>>>>>> identification of the host). That's what the realm >>>>>>>> portion of the NAI >>>>> is >>>>>>> for >>>>>>>> (in other IETF specs), and that's how it is also used in >>>>>>>> this spec as >>>>>>> well. >>>>>>>> I hope this clarifies. >>>>>>> Alper - what is 'roaming'? >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>>> Alper Samsung >>>>>>>> >>>>>>>>> -----Original Message----- From: mext-bounces@ietf.org >>>>>>>>> [mailto:mext-bounces@ietf.org] On Behalf >>>>> Of >>>>>>>>> Alexandru Petrescu Sent: Wednesday, April 30, 2008 >>>>>>>>> 12:41 PM To: heejin.jang@samsung.com Cc: >>>>>>>>> lprosee@gmail.com; mext@ietf.org Subject: Re: [MEXT] >>>>>>>>> why having DHCP do DNS resolution? (was: FW: >>>>>>> Summary >>>>>>>>> for the changes in hiopt-13) >>>>>>>>> >>>>>>>>> Heejin Jang wrote: >>>>>>>>>> Hi, Alex. See below. >>>>>>>>>> >>>>>>>>>> ps> I'm supposed to have a vacation till next Monday, >>>>>>>>>> and cannot access my samsung account. So kindly >>>>>>>>>> refer my gmail account as well. >>>>>>>>> Heejin, enjoy vacations :-) when back in office see >>>>>>>>> below. >>>>>>>>> >>>>>>>>> >>>>>>>>> [...] >>>>>>>>>>> Then I don't see why stateless DHCPv6 is needed for >>>>>>>>>>> this? Plain full DHCPv6 can accommodate this >>>>>>>>>>> scenario. >>>>>>>>>>> >>>>>>>>>> Basically plain (stateful) DHCPv6 is used for address >>>>>>>>>> configuration while stateless DHCPv6 is for other >>>>>>>>>> parameters configuration such as DNS server address. >>>>>>>>>> So this HN information should be delivered through >>>>>>>>>> stateless DHCPv6. >>>>>>>>> Let's clarify this use of Stateless DHCPv6 RFC3736. >>>>>>>>> >>>>>>>>> Why does a hiopt MN need to include a Home Network >>>>>>>>> Identifier (Sub-Opt-Code 1, eg realm of NAI) in the >>>>>>>>> Home Network Information >>>>>>> Option >>>>>>>>> in the Information-Request? Why isn't it sufficient to >>>>>>>>> use the >>>>> Client >>>>>>>>> Identifier Option DUID section 22.2 of RFC 3315 DHCPv6. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Why isn't the DUID enough to identify the Client (1 - >>>>>>>>> Link-layer >>>>>>> address >>>>>>>>> plus time, 2 - vendor-assigned unique id based on >>>>>>>>> enterprise number, >>>>> 3 >>>>>>> - >>>>>>>>> link-layer address). >>>>>>>>> >>>>>>>>> Why is it thought that it is necessary to specify Home >>>>>>>>> Network Identifier Sub-Opt-Code 1 as being, for >>>>>>>>> example, the realm part of a NAI, when the DUID exists, >>>>>>>>> is used and covers a different range of >>>>>>> cases. >>>>>>>>>>>> I think that RFC doesn't suggest the Client to >>>>>>>>>>>> put data in a request and the Server to suggest >>>>>>>>>>>> back a different data. Or, apparently, a >>>>>>>>>>>> hiopt-13 Client puts IPv6 home network prefix >>>>>>>>>>>> in a Request, with sub-opt-code equal 2, Relay >>>>>>>>>>>> forwards it to Server, and Server puts another >>>>>>>>>>>> IPv6 home network prefix in a Reply, >>>>>>>>>>>> apparently. Is this the intended hiop-13 >>>>>>>>>>>> behaviour? >>>>>>>>>>>> >>>>>>>>>>>> Is this behaviour in this sense completely >>>>>>>>>>>> different than the typical >>>>>>>>>>>> >>>>>>>>>>>> DHCPv6 operation? >>>>>>>>>>>> Section 3.3 says >>>>>>>>>>>> >>>>>>>>>>>> " While the Sub-opt-code 1 is only available in >>>>>>>>>>>> both the requesting and the returned Home Network >>>>>>>>>>>> Information options, Sub-opt-codes 2, 3, 4, and >>>>>>>>>>>> 5 are available only in the returned Home Network >>>>>>>>>>>> Information option and the MIP6 Relay Agent >>>>>>>>>>>> option." >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Section 4.1 says >>>>>>>>>>>> >>>>>>>>>>>> " A value of 1 is the only Sub-opt-code >>>>>>>>>>>> available in the request." >>>>>>>>> Right, now makes better sense. For easing my humble >>>>>>>>> reading this statement could appear in section 3.1 >>>>>>>>> where the message encoding of >>>>>>> Home >>>>>>>>> Network Information Option is described. >>>>>>>>> >>>>>>>>>>>> An MN cannot carry sub-opt-codes other than 1. >>>>>>>>>>>> This means that a sub-option in the request is >>>>>>>>>>>> used only to carry the MN's prefered target MSP >>>>>>>>>>>> in case of id-type 1 so that the server can reply >>>>>>>>>>>> the matching HA information. >>>>>>>>>>>> >>>>>>>>>>>> So, the server never replys with "the different" >>>>>>>>>>>> data. >>>>>>>>>>> Right, thanks, now I understand it better as being >>>>>>>>>>> the basic hiopt behaviour. >>>>>>>>>>> >>>>>>>>>>> Let me agree with you for a short while that it's >>>>>>>>>>> good to identify the subnet by a FQDN. >>>>>>>>>>> >>>>>>>>>>> If so basically MN (DHCP Client) puts FQDN in the >>>>>>>>>>> request and the DHCP Server sends back an IP >>>>>>>>>>> address of the Home Agent. >>>>>>>>>>> >>>>>>>>>>> How is this different than DNS Resolution? Why do >>>>>>>>>>> we need DHCP to do DNS Resolution? >>>>>>>>>> While MNs are required to know an exact FQDN of the >>>>>>>>>> target (HA) for DNS resolution, DHCP discovery >>>>>>>>>> enables HA discovery in variable ways even in case MN >>>>>>>>>> does not have exact information about its home >>>>>>>>>> network. For e.g. it can request the local HAs with >>>>>>>>>> the id-type 0. >>>>> Or >>>>>>>>>> the server may return partially matching HA >>>>>>>>>> information as >>>>> described >>>>>>>>>> in Section 4.3. >>>>>>>>> I agree at high level but not in detail. >>>>>>>>> >>>>>>>>> The really big problem here - and in all bootstrapping >>>>>>>>> documents - is that we have not precisely described >>>>>>>>> what is the information >>>>> available >>>>>>>>> at the MN prior to bootstrapping phase. Different >>>>>>>>> documents make different assumptions and they overlap. >>>>>>>>> >>>>>>>>> [skipped some for focusing the discussion] >>>>>>>>> >>>>>>>>>> IMHO, such a load-balancing approach is wellknown and >>>>>>>>>> does not need to be limited to VPN. Anyway here the >>>>>>>>>> key point is "to provide HA information based on NAI" >>>>>>>>>> can be implemented in various ways as >>>>> least >>>>>>>>>> by using 1) and 2) as described in previous mails. >>>>>>>>> If it is the key point then it should be much more >>>>>>>>> clear than that. It is far from being clear. Now here >>>>>>>>> it's said "NAI" but in the document it's said "for >>>>>>>>> example, the realm part of NAI". If we >>>>> decide >>>>>>>>> to do only NAI-based HA address bootstrapping with >>>>>>>>> DHCPv6 then I can agree we can have a better document. >>>>>>>>> >>>>>>>>> That is a big if. >>>>>>>>> >>>>>>>>> Because - does DHCPv6 or DHCPv4 ever use NAI for >>>>>>>>> address allocation >>>>> or >>>>>>>>> parameter configuration? I don't think so. They use >>>>>>>>> MAC address (or DUID) but not NAI. I find hiopt very >>>>>>>>> much different than DHCPv6 in >>>>>>> this >>>>>>>>> sense. IMHO. ?. >>>>>>>>> >>>>>>>>> If one wants to use NAI (or its realm part) to find the >>>>>>>>> corresponding >>>>>>> IP >>>>>>>>> address then use DNS straight resolution, not DHCP. >>>>>>>>> >>>>>>>>> Alex >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>> ______________________________________________________________________ >>>>> >>>>> >>>>> >>>>>>>>> This email has been scanned by the MessageLabs Email >>>>>>>>> Security System. For more information please visit >>>>>>>>> http://www.messagelabs.com/email >>>>>>>>> >>>>> ______________________________________________________________________ >>>>> >>>>> >>>>> >>>>>>>>> _______________________________________________ MEXT >>>>>>>>> mailing list MEXT@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>> ______________________________________________________________________ >>> >>> >>>>>>> This email has been scanned by the MessageLabs Email >>>>>>> Security System. For more information please visit >>>>>>> http://www.messagelabs.com/email >>>>>>> >>> ______________________________________________________________________ >>> >>> >>>>> ______________________________________________________________________ >>>>> This email has been scanned by the MessageLabs Email Security >>>>> System. For more information please visit >>>>> http://www.messagelabs.com/email >>>>> ______________________________________________________________________ >>>>> >>>>> >>>>> >>>> >>> >>> ______________________________________________________________________ >>> This email has been scanned by the MessageLabs Email Security >>> System. For more information please visit >>> http://www.messagelabs.com/email >>> ______________________________________________________________________ >>> >>> >> >> > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue May 13 08:22:00 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58B0E3A6C37; Tue, 13 May 2008 08:22:00 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96D5A3A6C36 for ; Tue, 13 May 2008 08:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmPyNikM4m2R for ; Tue, 13 May 2008 08:21:57 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id 9282628C335 for ; Tue, 13 May 2008 08:20:04 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so2373769fga.41 for ; Tue, 13 May 2008 08:19:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=FLdfFYYLKdpG1HDvY1g+bkZgxAcVYNyd2w4CErUPBXE=; b=CLddLNx7CLeze6Hj13Lo+f0GWRYaHTTJectwnJKq4pnVVreEdHJxiERkLINozPG8e68JeleYJVjF5RxaJkwSxxGxfz+MA8qNno8cQnaHCkYlrnMUvdr8nslkGrSLBLD/9Goz38mLRHk33hsNTTd6tXL7fzx+UQDi/gB40UZIu94= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=jjcs1+wWgzx9aEPYv39nVLeaZztlZhyPGl1vWCFjAJ+am8+3c4yV5epqalq63f+gIYhEFgA8dFjcgSI7Bt/gn0hldZ7NDTeoaIcKqYYPxiat0hucLJD+GXuaIWl+bHxYENdW0CHv0tWVUsvJEXssQ0l40zKNYgifdSuDSMtYBFE= Received: by 10.86.89.4 with SMTP id m4mr16677712fgb.55.1210691949536; Tue, 13 May 2008 08:19:09 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id 22sm13916388fkr.11.2008.05.13.08.19.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 13 May 2008 08:19:08 -0700 (PDT) From: Julien Laganier To: mext@ietf.org Date: Tue, 13 May 2008 17:19:04 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <0MKpCa-1JvtlB14Vo-0003bV@mrelay.perfora.net> <4829A270.4060705@gmail.com> In-Reply-To: <4829A270.4060705@gmail.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200805131719.05573.julien.IETF@laposte.net> Cc: lprosee@gmail.com Subject: Re: [MEXT] why having DHCP do DNS resolution? (was: FW: Summary for the changes in hiopt-13) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Tuesday 13 May 2008, Alexandru Petrescu wrote: > Alper Yegin wrote: > > I can only answer this for myself. I am not aware of any IPRs on > > this I-D. > > Alper - thanks for the clarifications. > > Let me summarize: =A0one thinks there's no IPR on the doc, the document > was not prototyped/implemented, the document is being referred by > 3GPP2 and by WiMax, and technically there appears to be some > miscomprehension from me about the use of NAI to discover a HA with > DHCP (as opposed to using a DUID). > > In this context, do you think the document should be progressed on > the Standards Track? > > In my experience, I recognize this situation as a typical situation > which would progress a draft on the Informational track. > > I hope this clarifies my part of it. =A0I will let other WG members > express about the hiopt situation - what do other people think? Alex, As a working group chair I'd like to suggest that we conclude this = discussion now. The MIP6 WG was chartered to publish as a proposed = standard a specification for "DHCP Options for Home Information = Discovery in MIPv6". Thus it's not longer time to discuss whether such = a specification shall be informational. Thanks in advance for your understanding. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue May 13 10:15:05 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F01CE3A68F2; Tue, 13 May 2008 10:15:04 -0700 (PDT) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A74EA3A68F2; Tue, 13 May 2008 10:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080513171501.A74EA3A68F2@core3.amsl.com> Date: Tue, 13 May 2008 10:15:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-aero-reqs-02.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : NEMO Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks Author(s) : W. Eddy, et al. Filename : draft-ietf-mext-aero-reqs-02.txt Pages : 30 Date : 2008-05-13 This document describes the requirements and desired properties of NEMO Route Optimization techniques for use in global networked communications systems for aeronautics and space exploration. This version has been reviewed by members of the International Civil Aviation Orgnanization (ICAO) and other aeronautical communications standards bodies, and contributed to by a number of aeronautical communications experts outside the normal IETF process. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-aero-reqs-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-mext-aero-reqs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-13100608.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --NextPart-- From fieryskies@hotmail.com Tue May 13 13:13:19 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 837CB3A683B for ; Tue, 13 May 2008 13:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -66.928 X-Spam-Level: X-Spam-Status: No, score=-66.928 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHs7QLdQWv43 for ; Tue, 13 May 2008 13:13:18 -0700 (PDT) Received: from [71.61.51.153] (c-71-61-51-153.hsd1.pa.comcast.net [71.61.51.153]) by core3.amsl.com (Postfix) with ESMTP id 5FB533A67AE for ; Tue, 13 May 2008 13:13:17 -0700 (PDT) Received: from [71.61.51.153] by mx4.hotmail.com; Tue, 13 May 2008 14:13:16 -0600 From: "Google AdWords" To: Subject: Submit your payment information. Date: Tue, 13 May 2008 14:13:16 -0600 Message-ID: <01c8b503$7c992600$99333d47@fieryskies> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C8B503.7C992600" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C8B503.7C992600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit ------------------------------------------------------------------------------ Dear Google AdWords Customer, We were unable to process your payment. Your ads will be suspended soon unless we can process your payment. To prevent your ads from being suspended, please update your payment information. Please sign in to your account at http://adwords.google.com/select/login, and update your payment information. -------------------------------------------------------------------------------------------- This message was sent from a notification-only email address that does not accept incoming email. Please do not reply to this message. ---------------------------------------------------------------------------------------------- We look forward to providing you with the most effective advertising available. Thank you for choosing AdWords. ------=_NextPart_000_000E_01C8B503.7C992600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -------------------------------------------------------------------------= --------------
Dear Google AdWords Customer,

We were unable to process your payment.
Your ads will be suspended soon unless we can process your payment.
To prevent your ads from being suspended, please update your payment info= rmation.

Please sign in
to your account at http://adwords.google.com/select/login,
and update your payment information.

-------------------------------------------------------------------------= --------
This message was sent from a notification-only email address that does not accept incoming email. Please do not reply to this message.
-------------------------------------------------------------------------= --
------=_NextPart_000_000E_01C8B503.7C992600-- From mext-bounces@ietf.org Tue May 13 22:52:39 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FCC43A6A12; Tue, 13 May 2008 22:52:39 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A02F03A6940; Tue, 13 May 2008 22:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=-0.438, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+oAn9gOpqvm; Tue, 13 May 2008 22:52:33 -0700 (PDT) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by core3.amsl.com (Postfix) with ESMTP id A43843A6885; Tue, 13 May 2008 22:51:25 -0700 (PDT) Received: from ep_ms5_bk (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K0U004F6G901H@mailout1.samsung.com>; Wed, 14 May 2008 14:51:00 +0900 (KST) Received: from ep_spt02 (ms5.samsung.com [203.254.225.113]) by ms5.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K0U00E09G8ZT1@ms5.samsung.com>; Wed, 14 May 2008 14:51:00 +0900 (KST) Content-return: prohibited Date: Wed, 14 May 2008 05:50:59 +0000 (GMT) From: Heejin Jang To: jari.arkko@piuha.net Message-id: <31987307.714021210744259758.JavaMail.weblogic@epml04> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20080514054130072@heejin.jang X-MTR: 20080514054130072@heejin.jang X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML Cc: draft-ietf-mip6-hiopt@tools.ietf.org, mext-chairs@tools.ietf.org, dhc-chairs@tools.ietf.org, iesg@ietf.org, "mext@ietf.org" Subject: [MEXT] Submission of new draft (hiopt-16) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: heejin.jang@samsung.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Jari and folks. I'd like to let you know that the latest version of draft-ietf-mip6-hiopt has been posted. (http://www.ietf.org/internet-drafts/draft-ietf-mip6-hiopt-16.txt) Based on Vijay's comments, we gave a modification slightly in Sections for Introduction and IANA. Thanks Vijay and AD again for your kind cooperation. - Best regards, Heejin _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed May 14 07:00:36 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3B2B3A67F7; Wed, 14 May 2008 07:00:35 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98E793A6854 for ; Wed, 14 May 2008 07:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJClrb0SobXe for ; Wed, 14 May 2008 07:00:26 -0700 (PDT) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.188]) by core3.amsl.com (Postfix) with ESMTP id D3D5D3A67F7 for ; Wed, 14 May 2008 07:00:25 -0700 (PDT) Received: by mu-out-0910.google.com with SMTP id g7so1888549muf.9 for ; Wed, 14 May 2008 06:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=SjWVLNWUI/OCjnOpxN7E/GreMTTK8dcVp5joT/OxzQA=; b=c1gmTrzuy/cH2PjcEq7V3vv9ToaHlMz1qhX7Nqt8jeLw/EquuqrT/iDAZfpGNUiGw4Z+3dEEvhEoSnickUXqHxhTaM1/zPLSxFfZPgyl4LCff+JhuGjvhuEhX8YArNgutiQzu83gWAtv8Qnt8qKwGdaiojupMUc5iev5w0CP/XQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=WM/iY5ug3HlxGXzqQ+q0YcOzLdDlFx4mqP/e05AryNpGXQg+jPvaG1E3lvwUyb5eHv6JG6DDtjHTMdd8damZj9ujU+AR3nJxwkddjcXJs+BIXtLy8t3K8WtPmjt4orAsTjIJmmvy2S09EYUycCNuvLaxmnWFRIPixvny7R1S4RM= Received: by 10.125.133.13 with SMTP id k13mr424722mkn.25.1210773574128; Wed, 14 May 2008 06:59:34 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id 13sm1788552fks.12.2008.05.14.06.59.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 14 May 2008 06:59:33 -0700 (PDT) From: Julien Laganier To: mext@ietf.org, "George Tsirtsis" Date: Wed, 14 May 2008 15:59:25 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <20080501181501.BCA813A68CC@core3.amsl.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200805141559.27518.julien.IETF@laposte.net> Subject: Re: [MEXT] Fwd: I-D ACTION:draft-ietf-mext-nemo-v4traversal-02.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello George, On Wednesday 07 May 2008, George Tsirtsis wrote: > Hi Julien/Marcelo et.al., > > Are we done with the WGLC for this ? Anything else needed before we > progress this further? Hesham is fixing three last things and then it shall be ready for IESG. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed May 14 08:30:03 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95C1E3A692A; Wed, 14 May 2008 08:30:03 -0700 (PDT) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F2CA53A6949; Wed, 14 May 2008 08:30:01 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Mime-Version: 1.0 Message-Id: <20080514153001.F2CA53A6949@core3.amsl.com> Date: Wed, 14 May 2008 08:30:01 -0700 (PDT) Cc: mext@ietf.org, julien.ietf@laposte.net Subject: [MEXT] WG Review: Recharter of Mobility EXTensions for IPv6 (mext) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: iesg@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org A modified charter has been submitted for the Mobility EXTensions for IPv6 working group in the Internet Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by May 21, 2008. Mobility EXTensions for IPv6 (mext) -------------------------------------------------- Current Status: Active Working Group Last Modified: 2008-05-08 Additional information is available at tools.ietf.org/wg/mext Chair(s): Julien Laganier Marcelo Bagnulo Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: mext@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/mext Archive: http://www1.ietf.org/mail-archive/web/mext/current Description of Working Group: Mobile IPv6 specifies routing support which permits an IPv6 host to continue using its home address as it moves around the Internet, enabling continuity of sessions. Mobile IPv6 supports transparency above the IP layer, including maintenance of active transport level sessions. In addition, network mobility (NEMO) mechanisms built on top of Mobile IPv6 allow managing the mobility of an entire network, as it changes its point of attachment to the Internet. The base specifications consist of: o RFC 3775 (Mobile IPv6) o RFC 3963 (NEMO) o RFC 4877 (Mobile IPv6 Operation with IKEv2) The MEXT Working Group continues the work of the former MIP6, NEMO, and MONAMI6 Working Groups. The primary goal of MEXT will be to (A) enhance base IPv6 mobility by continuing work on developments that are required for wide-scale deployments and specific deployment scenarios. Additionally, (B) the working group will ensure that any issues identified by implementation and interoperability experience are addressed, and that the base specifications are maintained. (C) The group will also produce informational documentation, such as design rationale documents or description of specific issues within the protocol. Deployment considerations call for (A.1) solutions to enable dual-stack operation, (A.2) mechanisms to support high-availability home agents, (A.3) allowing the use of multiple interfaces in mobile nodes, (A.4) ways to employ Mobile IPv6 in the presence of firewalls, (A.5) address the specific needs of automotive and aviation communities for route optimisation in network mobility, (A.6) support for AAA is needed as a continuation of earlier work on bootstrapping, (A.7) revocation of binding, (A.8) generic notification message format and (A.9) extended DMSIP home network support . Work items related to large scale deployment include: (A.1) A Solution for Mobile IPv6 and NEMO session continuity for dual stack hosts which attach to IPv4 access networks. Additionally provide a mechanism for carrying IPv4 packets via the Home agent for Mobile IPv6 or NEMO capable dual-stack hosts. (A.2) A protocol based solution for enhancing the reliability of home agents and a method to force a host/router to switch home agents. A mechanism to force an MN to switch the HA that is currently serving it. This is required in deployments where the HA needs to be taken offline for maintenance. (A.3) Use of multiple interfaces. Today, the protocols do not provide suppport for simultaneous differentiated use of multiple access technologies. Several proposals exist for such support, and some of them have been implemented and tested. When a mobile host/router uses multiple network interfaces simultaneously, or when multiple prefixes are available on a single network interface, the mobile host/router would end up with multiple Care-of Addresses (CoAs). In addition, the Home Agent might be attached to multiple network interfaces, or to a single network interface with multiple prefixes, hence resulting in the option to use multiple IP addresses for the Home Agent. This could result in the possibility of using a multitude of bi-directional tunnels between pairs of {Home Agent address, CoA} and a number of associated issues: establishment, selection and modification of multiple simultaneous tunnels. The objective of the WG is to produce a clear problem statement and to produce standard track specifications to the problems associated with the simultaneous use of multiple addresses for either mobile hosts using Mobile IPv6 or mobile routers using NEMO Basic Support and their variants (FMIPv6, HMIPv6, etc). Where the effects of having multiple prefixes on a single interface is identical to the effects of having multiple interfaces each with a single prefix, the WG will consider a generalized approach to cater for multiple prefixes available to a mobile host/router. The WG uses existing tunneling mechanisms defined for Mobile IPv6. The involved nodes need to select which tunnel instance to use when multiple ones are available due to multiple addresses on either end. But the WG does not plan to define a new mechanism for this, but rather document how to use existing mechanisms based upon preferences or policies. In particular, the WG will consider that a tunnel is alive as long as packets can be exchanged with the corresponding peer. In addition, local information, such as interface up/down events, or other failure detection mechanisms can be used to quickly detect failure of tunnel(s). Deliverables related to this include - A document explaining the motivations for a node using multiple interfaces and the scenarios where it may end up with multiple global addresses on its interfaces [Informational] - An analysis document explaining what are the limitations for mobile hosts using multiple simultaneous Care-of Addresses and Home Agent addresses using Mobile IPv6, whether issues are specific to Mobile IPv6 or not [Informational]. - A protocol extension to support the registration of multiple Care-of Addresses at a given Home Agent address [Standard Track]. - A "Flow/binding policies exchange" solution for an exchange of policies from the mobile host/router to the Home Agent and from the Home Agent to the mobile host/router influencing the choice of the Care-of Address and Home Agent address. The solution involves two specifications, one for the policy format and another for its transport [both Standard Track]. (A.4) Work on solutions to deal with firewalls and the problems that firewalls cause as identified in RFC 4487. (A.5) Route optimization of network mobility. Three use cases have been identified for this. These are called the Aviation case, the Automotive case, and the Personal Mobile Router (consumer electronics) case, though the actual technical problems are characterized by the type of movements and environments more than by the specific industry using the technology. The group will explore these cases to gather requirements and proceed with solving the open issues. (1) Airline and spacecraft community, who are deploying NEMO for control systems, as well as Internet connectivity and entertainment systems. This use case is characterized by fast (~ 1000 km/h) moving objects over large distances (across continents). The main technical problem is that tunneling-based solutions imply a roundtrip to another continent and that BGP based solutions imply significant churn in the global Internet routing table. (2) Automotive industry who are deploying NEMO for in-car communication, entertainment, and data gathering, possible control systems use, and communication to roadside devices. This use case is characterized by moderately fast (~ 100-300 km/h) moving objects that employ local or cellular networks for connectivity. (3) Personal Mobile Routers, which are consumer devices that allow the user to bring a NEMO network with the user while mobile, and communicate with peer NEMO Basic Support nodes and nodes served by them. After gathering the requirements for these types of deployments, the working group will evaluate what type of route optimization needs to be performed (if any), and formulate a solution to those problems. If no requirements for those scenarios can be collected by the deadline, it will be assumed that the work is premature, and that type of deployment will be dropped from the WG. The group will only consider airline and spacecraft solutions that combine tunneling solutions for small movements with either federated tunnel servers or slowly changing end host prefixes. The group will only consider personal mobile router requirements about optimized routes to another mobile router belonging to the same operator. The group will only consider automotive industry requirements to allow MR-attached hosts to directly access the network where MR has attached to. Work on automotive and personal mobile router solutions requires rechartering. The WG will not consider extensions to routing protocols. The group will not consider general multi-homing problems that are not related to the deployment and maintenance of Mobile IPv6 or NEMO Basic Support protocols. The group will also not consider general route optimization, or other problems that are not related to the deployment and maintenance of NEMO Basic Support protocols. Similarly, the group will not consider or rely on the results of general routing architecture, Internet architecture, or identifier-locator split issues that are discussed in separate, long term efforts elsewhere in the IETF. Finally, the group will not consider solutions that require changes from correspondent nodes in the general Internet (A.6) Bootstrapping mechanisms developed earlier in the MIP6 WG require AAA support for Mobile IPv6. Part of this work is already being done in the DIME WG, but the MEXT WG is chartered to complete a design for RADIUS. (A.7) Binding Revocation for IP Mobility: Define a binding revocation mechanism for Mobile IPv6 and its extensions. This mechanism can be used by any entity involved in the base Mobile IPv6 protocol or one of its extensions to request its corresponding entity to terminate either one, multiple or all binding cache entries. (A.8) Generic Notification Message for Mobile IPv6: A proposal for defining generic notification framework that can be used by the mobility entities for sending and receiving asynchronous notification messages was proposed and the same was adopted by the WG. (A.9) Extended DSMIPv6 Home Network Support: DSMIPv6 assumes the home network to be dual stack providing simultaneous IPv6 and IPv4 network access. It is proposed to extend DSMIPv6 to support home networks which provides IPv4, or IPv6 respectively, direct network access only, but where virtual IPv6 home network connectivity, or virtual IPv4 home network connectivity respectively, may be obtained by tunneling to the HA. The latter shall be obtained by DSMIPv6 operation using the v4HoA address as Care-of-address for the v6HoA address, and vice versa, the v6HoA address as care-of-address for the v4HoA address. Work items related to base specification maintenance include: (B.1) Create and maintain issue lists that are generated on the basis of implementation and interoperability experience. Address specific issues with specific updates or revisions of the base specification. One specific area of concern that should be analyzed and addressed relates to multilink subnets. This work item relates only to corrections and clarifications. The working group shall not revisit design decisions or change the protocol. (B.2) Update the IANA considerations of RFC 3775 to allow extensions for experimental purposes as well passing of optional vendor-specific information. (B.3) Finish working group documents that are currently in process, and submit for RFC. This includes prefix delegation protocol mechanism for network mobility, and a MIB for NEMO Basic Support. Work items related to informational documentation include: (C.1) Produce a design rationale that documents the historical thinking behind the introduction of an alternative security mechanism, the Authentication Protocol (RFC 4285). (C.2) Virtual Home Link configuration for Mobile IPv6: A proposal has been made on Mobile IPv6 home link configuration on virtual links. The proposal does not describe any new protocol, but provides the operational and configuration details and additionally provides implementation guidance for achieving this configuration. The group employs IPsec and IKE as a security mechanism. The group shall refrain, however, from making generic extensions to these protocols. Any proposed extension must be reviewed by the INT and SEC ADs before it can be accepted as a part of a work item. Goals and Milestones: Done Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for publication as a Proposed Standard Dec 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for publication as a Proposed Standard. Dec 2007 Submit I-D 'Motivation for Authentication I-D' to IESG for publication as Informational. Dec 2007 Submit Multiple CoA Registration to IESG Done Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG for publication as a Proposed Standard Feb 2008 Submit I-D 'Goals for AAA HA Interface' to IESG for publication as Informational. Feb 2008 Submit -00 draft on Route Optimization needs for Personal Mobile Router Feb 2008 Submit -00 draft on Route Optimization Needs for Automobile and Highway Deployments Feb 2008 Submit -00 draft on Route Optimization Needs for Aircraft and Spacecraft Deployments Mar 2008 Submit the final doc on Prefix Delegation for NEMO to the IESG, for Proposed Standard Done Submit I-D 'Mobility Header Home Agent Switch Message' to IESG for publication as a Proposed Standard May 2008 Submit final doc on Route Optimization needs for Personal Mobile Router, for Informational May 2008 Submit final doc on Route Optimization Needs for Automobile and Highway Deployments, for Informational May 2008 Submit final doc on Route Optimization Needs for Aircraft and Spacecraft Deployments, for Informational May 2008 Submit -00 draft for solution to aircraft/spacecraft problem Jun 2008 Determine how to proceed with remaining automotive/Personal Mobile Router solutions Jun 2008 Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for publication as a proposed standard. June 08 Submit 00 draft on Binding Revocation Jul 2008 Submit Analysis of the use of Multiple Simultaneous Care-of Addresses and Home Agent addresses, for Informational Jul 2008 Submit Multiple Interfaces Motivations and Scenario to IESG, for Informational Aug 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication as Informational. Aug 2008 Submit the final doc on MIB for NEMO Basic Support to the IESG, for Proposed Standard Oct 2008 Submit Flow/binding policy transport to IESG, for Proposed Standard Oct 2008 Submit Flow/binding policy format to IESG, for Proposed Standard Oct 08 Submit 00 draft on Generic Notification Oct 08 Submit draft on Binding Revocation to IESG Nov 2008 Submit final doc for solution to aircraft/spacecraft problem to the IESG, for Proposed Standard Nov 2008 Recharter to work on the remaining automotive/Personal Mobile Router solutions Dec 08 Submit 00 draft on Virtual Home link configuration Dec 08 Submit 00 draft on Extended DSMIPv6 Home Network support Dec 2008 Submit I-D(s) related to specific updates and corrections of RFC 3775 to IESG for publication as Proposed Standard. Dec 2008 Submit I-D 'Home agent reliability' to IESG for publication as a Proposed Standard. Jan 09 Submit draft on Generic Notification to IESG Mar 09 Submit draft on Virtual Home link configuration to IESG May 09 Submit draft on Extended DSMIPv6 Home Network support to IESG _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 15 09:46:17 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76C043A68A4; Thu, 15 May 2008 09:46:17 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E7223A68D6 for ; Thu, 15 May 2008 09:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MI9pO9AEKA8J for ; Thu, 15 May 2008 09:46:10 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.186]) by core3.amsl.com (Postfix) with ESMTP id 2493E3A68A4 for ; Thu, 15 May 2008 09:46:06 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so340210tib.25 for ; Thu, 15 May 2008 09:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=DCAaVhMoodfQhbVDL1rxDmnmAKSNoqF20V12zNWcYdo=; b=RjA5exhuJI0/QeTBUW/94wWKY6/PZxmuyIpdxQW0NXtylv6q6AcJSQ0blLhpJHc7RDe+zA/O3QD7A1eyrNmVguJsKsBQtjp9hTPISjmx2MsVApCAq6IMf6XFV0j9FqK/mJdy/VXdQK6kLiS78FBAA8FtZo1G9CjOiYeCmxHEPvg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=I4lZFdS8vEpaOUAv0i6OiheZFt9+gPDOgLj9CkbjogthIx0kfsGz4jEpF1nsxixy3hx50RPDJeCl7+PUI+IWBLw0Hn1mT4mMrDZSYRn5aMayd079w5RF23wtcU38RmkuKYQ0DFtrobUaz2oT67JLoV2G+5raYPP0hkmft3LcPw0= Received: by 10.110.70.5 with SMTP id s5mr337571tia.27.1210868229792; Thu, 15 May 2008 09:17:09 -0700 (PDT) Received: by 10.110.93.4 with HTTP; Thu, 15 May 2008 09:17:09 -0700 (PDT) Message-ID: <1d38a3350805150917y507f0194u20f636f04e3a82fc@mail.gmail.com> Date: Fri, 16 May 2008 00:17:09 +0800 From: "Hui Deng" To: Pasi.Eronen@nokia.com In-Reply-To: <1696498986EFEC4D9153717DA325CB729CB469@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 Content-Disposition: inline References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> <873aouxsad.fsf@natisbad.org> <1696498986EFEC4D9153717DA325CB729CB469@vaebe104.NOE.Nokia.com> Cc: ipsec@ietf.org, mext@ietf.org Subject: Re: [MEXT] [IPsec] IPsec maintenance/extensions WG, summary so far X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org thanks Pasi's elaboration, see inline with ==> Please allow me to cc MEXT, 2008/5/14 : > Arnaud Ebalard wrote: > >> Sorry for joigning the discussion a little bit late. I should have >> posted to make a proposal for some work on MIPv6/IPsec/IKE >> interactions as WG items before. >> >> The IPsec-related elements you cite in your P.S. for MEXT were *not* >> taken as Working Group items during the recent recharter (decision >> of the chairs) even if there were people interested by working on >> it. Some other functionalities have been preferred. >> >> At the moment, even if MIPv6 specification expects interactions >> between IPsec stack and MIPv6 module for IPSec to survive movement, >> no interface is defined. The 2 proposals I am aware of on that >> topic: >> >> - draft-sugimoto-mip6-pfkey-migrate-04 >> - draft-qi-mip6-ikev2-interfacing-01 >> >> are still now simple external documents. >> >> IMO, the main issue here is that the topic crosses different WG or >> is related to different subjects (IPsec, MIPv6, IKE, PF_KEY). As you >> wrote for the IPsec WG "the intent is *not* to collect all >> IPsec-related work to one WG". >> >> What is happening in practice is that IPsec and MIPv6 will be >> *separately* added new features (probably useful in a sense) but >> will not or badly work together. >> >> Where should associated efforts and discussions be handled? > > When I mentioned Mobile IP specific extensions to IPsec, I meant > things like RFC 5026. ==> So here you mean that it will be in the scope of Mobile IP WG? after that, it need Security review for this kind of work? thanks -Hui > > As I wrote in my email, I think PF_KEY work does not fit within > the scope of the possible WG charter (at least not now). > > Best regards, > Pasi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 15 13:00:25 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24BCD3A6892; Thu, 15 May 2008 13:00:25 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B35FA3A68D9; Thu, 15 May 2008 13:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.061 X-Spam-Level: X-Spam-Status: No, score=-6.061 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9G1Z8gp1FZl5; Thu, 15 May 2008 13:00:22 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 9B32C3A67FB; Thu, 15 May 2008 13:00:21 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4FK0762017170; Thu, 15 May 2008 23:00:12 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 May 2008 23:00:11 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 May 2008 23:00:10 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 15 May 2008 23:00:10 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72A13653@vaebe104.NOE.Nokia.com> In-Reply-To: <1d38a3350805150917y507f0194u20f636f04e3a82fc@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] IPsec maintenance/extensions WG, summary so far Thread-Index: Aci2py1E5qlFgPFNTAW5RIzgqvYfLgAHeLTg References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> <873aouxsad.fsf@natisbad.org> <1696498986EFEC4D9153717DA325CB729CB469@vaebe104.NOE.Nokia.com> <1d38a3350805150917y507f0194u20f636f04e3a82fc@mail.gmail.com> From: To: X-OriginalArrivalTime: 15 May 2008 20:00:10.0810 (UTC) FILETIME=[480499A0:01C8B6C6] X-Nokia-AV: Clean Cc: ipsec@ietf.org, mext@ietf.org Subject: Re: [MEXT] [IPsec] IPsec maintenance/extensions WG, summary so far X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hui Deng wrote: > >> Sorry for joigning the discussion a little bit late. I should have > >> posted to make a proposal for some work on MIPv6/IPsec/IKE > >> interactions as WG items before. > >> > >> The IPsec-related elements you cite in your P.S. for MEXT were > >> *not* taken as Working Group items during the recent recharter > >> (decision of the chairs) even if there were people interested by > >> working on it. Some other functionalities have been preferred. > >> > >> At the moment, even if MIPv6 specification expects interactions > >> between IPsec stack and MIPv6 module for IPSec to survive movement, > >> no interface is defined. The 2 proposals I am aware of on that > >> topic: > >> > >> - draft-sugimoto-mip6-pfkey-migrate-04 > >> - draft-qi-mip6-ikev2-interfacing-01 > >> > >> are still now simple external documents. > >> > >> IMO, the main issue here is that the topic crosses different WG or > >> is related to different subjects (IPsec, MIPv6, IKE, > >> PF_KEY). As you wrote for the IPsec WG "the intent is *not* to > >> collect all IPsec-related work to one WG". > >> > >> What is happening in practice is that IPsec and MIPv6 will be > >> *separately* added new features (probably useful in a sense) but > >> will not or badly work together. > >> > >> Where should associated efforts and discussions be handled? > > > > When I mentioned Mobile IP specific extensions to IPsec, I meant > > things like RFC 5026. > > ==> So here you mean that it will be in the scope of Mobile IP WG? > after that, it need Security review for this kind of work? I'm not taking any opinion on whether these drafts should be in the scope of MEXT WG or not. (But as I said earlier, nothing in the IPsec maintenance/extensions WG discussion is intended to prevent other WGs from working on IPsec-related topics, if they choose to do so.) Best regards, Pasi _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 15 14:49:21 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCBF828C10F; Thu, 15 May 2008 14:49:20 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 780903A6A9D for ; Thu, 15 May 2008 14:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gI3vy8lQaezk for ; Thu, 15 May 2008 14:49:07 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.224]) by core3.amsl.com (Postfix) with ESMTP id 4714A3A6916 for ; Thu, 15 May 2008 14:49:07 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id 50so331266wra.13 for ; Thu, 15 May 2008 14:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=hvirITz9SPErrWgkpt7zy190dypx7dlOZ7J2P6geAic=; b=jsUL0pHtoBnW6yaW8HAofooVsaoL5tAAi5hDwbqyM2nbfFeu5Kkgi1QRApesmniDibQ5SObnx973P/y8eh4VI1zcaQPq5KXE2JKeQ+svEdeKcboPqd61YRiH7yKRdkBuo/btOrZXZzcXjuxM+AEZG/ogQLP9CHv3BeWuVszzUiI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CK5MYDxMMcsYt6Szmb3zv06mg0HnX64AVWqnPcN+GYCW3gx/j7SR2eepFlGi53nW4yOXwtmsLHp6SR1bZFgjx0B9uAiTmyTlnZpB3BEINvekOZDVZH45+GTtoy54tqzzgZW0V84wQlJZfThJnIPAJodGwK68ir5wAjGPuafq8sc= Received: by 10.142.43.7 with SMTP id q7mr1194136wfq.328.1210888141575; Thu, 15 May 2008 14:49:01 -0700 (PDT) Received: by 10.142.200.13 with HTTP; Thu, 15 May 2008 14:49:01 -0700 (PDT) Message-ID: Date: Thu, 15 May 2008 14:49:01 -0700 From: "Vijay Devarapallli" To: "mext@ietf.org" In-Reply-To: <20080515214501.C0D823A6986@core3.amsl.com> MIME-Version: 1.0 Content-Disposition: inline References: <20080515214501.C0D823A6986@core3.amsl.com> Subject: [MEXT] Fwd: I-D Action:draft-devarapalli-ipsec-ikev2-redirect-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello, The draft at the URL below describes a mechanism for re-directing an IKEv2 initiator to another gateway during the IKE_SA_INIT exchange. This could be used for Mobile IPv6 also for a home agent to re-direct a mobile node to another home agent. Comments/reviews are welcome. Vijay ---------- Forwarded message ---------- From: Date: 2008/5/15 Subject: I-D Action:draft-devarapalli-ipsec-ikev2-redirect-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Re-direct Mechanism for IKEv2 Author(s) : V. Devarapalli, et al. Filename : draft-devarapalli-ipsec-ikev2-redirect-00.txt Pages : 11 Date : 2008-05-15 IKEv2 is a popular protocol for setting up VPN tunnels from a remote location to a gateway so that the VPN client can access services in the network behind the gateway. Currently there is no standard mechanism specified that allows an overloaded VPN gateway to re- direct the VPN client to attach to another gateway. This document proposes a re-direct mechanism for IKEv2. The proposed mechanism can also be used for Mobile IPv6 to enable the home agent to re-direct the mobile node to another home agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-devarapalli-ipsec-ikev2-redirect-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri May 16 02:44:40 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BD2228C168; Fri, 16 May 2008 02:44:40 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5517728C157; Fri, 16 May 2008 02:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soGXJg4NewSb; Fri, 16 May 2008 02:44:30 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id 5894428C15B; Fri, 16 May 2008 02:44:30 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1JwwU3-0000Hn-Fq; Fri, 16 May 2008 11:44:15 +0200 X-Hashcash: 1:20:080516:mext@ietf.org::YLRgfCTlUECeNlg3:00001SBo From: arno@natisbad.org (Arnaud Ebalard) To: "Vijay Devarapallli" References: X-GnuPG-Key: 0x047A5026 X-Hashcash: 1:20:080516:dvijay@gmail.com::wDenXdoey4TJUQtG:05aJJ X-Hashcash: 1:20:080516:ipsec@ietf.org::fvm/lR22ZBp33lGO:0008Snx Date: Fri, 16 May 2008 11:44:05 +0200 Message-ID: <87r6c2r3bu.fsf@natisbad.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: ipsec@ietf.org, mext@ietf.org Subject: Re: [MEXT] [IPsec] Redirect mechanism for IKEv2 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0031460654==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0031460654== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable Hi Vijay, "Vijay Devarapallli" writes: > The draft at the URL below describes a mechanism for re-directing an > IKEv2 initiator to another gateway during the IKE_SA_INIT exchange. > This could be used for Mobile IPv6 also for a home agent to re-direct > a mobile node to another home agent. > > Comments/reviews are welcome. Some comments below, with quoted parts from the draft. Sorry for cross-posting but the discussion probably belongs to both ML.=20 Mostly, the idea of the mechanim and the coverage looks ok to me but the relationships with MIPv6 does not. To summarize most of my comments, the draft makes the redirect mechanism happen at the IKE level and expects that it has no impact on the work of the MIPv6 part. In practice, the address of the Home Agent being also the address of the IKE GW and the IPsec SA (even if the negotiation could be modified to be for different addresses regarding the IPsec SA and the IKE GW), there is a need for synchronization between IKE and MIPv6. IMHO, this is missing in the draft and should be stated.=20 Note that this summary and some of my comments/questions below can also be applied to Section 9 of RFC 4877, which describes Dynamic Home Address configuration using IKEv2. For me, the redirect mechanism described in the draft is in some way the dual of the Dynamic HoA configuration using IKE described in section 9 of RFC 4877.=20 Basically: =2D triggering event: IKE seems to initiate connections just like that, without real triggering events, i.e. some packets being sent that require protection and match some selector of a SPD entry. =2D communications/synchronization: IKE is used (addresses here and in 4877) for configuring/negotiating MIPv6 parameters but the synchronization of those elements is not covered. I would also include the IPsec in the picture. In practice, the MIPv6 modules, the IKE daemon and the IPsec stack must work *together*. At the moment, some draft and RFC on those elements have expectation but do not cover the interactions between those elements.=20 If I missed some reference document or something obvious, don't hesitate to correct me. From=20the introduction: > Mobile IPv6 [3] uses IKEv2 for mutual authentication between the > mobile node and the home agent. IKEv2 is also used for home address > configuration and setting up IPsec security associations for > protecting Mobile IPv6 signaling messages [4]." uses -> may/can use. The mechanism is not required. IKEv1 is also usable, so using IKE without any version might be better here. > The IKEv2 exchange precedes the exchange of Mobile IPv6 signaling > messages. In practice, AFAICT, the IKE exchange is *triggered* by the emission of the BU. It seems that RFC 4877 has started to take a different direction where IKE is used to configure MIPv6, but the details are missing. > Therefore the mechanism described in this document can be also be=20 > used by a Mobile IPv6 home agent to re-direct a mobile node to > another home agent. Collusion between Key Manager and HA operation. > There is a Home Agent Switch mechanism available for re-directing a > mobile node to another home agent, described in [5]. The Home Agent > Switch mechanism can only be used after the binding cache had been > created at the home agent for the mobile node. The disadvantage with > this is that quite a bit of state is created on the home agent before > the mobile node can be re-directed to another home agent. The > mechanism described in this document can be used for re-directing a > mobile node before any state is created on the home agent. IMHO, there is a difference between IKE and MIPv6 operations: 1) A Home Agent is overloaded and start redirecting MN to another HA: for instance, it is already using all its available upload bandwidth for registered MN (which is unrelated to IPsec/IKE). 2) There are too many IKE peers connecting at the same time on an IKE daemon (for the setup of IPsec SA between MN and HA or common clients) and the IKE daemon starts redirecting clients to another IKE daemon. What I mean is that, AFAICT, the two mechanism solve different problems, through different channels. In section 3 > When the VPN client receives the IKE_SA_INIT response with the > REDIRECT payload, it initiates a new IKE_SA_INIT exchange with the > VPN gateway listed in the REDIRECT payload. The VPN client includes > the IP address of the original VPN gateway that re-directed the > client. The IKEv2 exchange then proceeds as normal with the selected > VPN gateway. IMHO, the last sentence simply does not cover the possible associated issues and how things should be done, *how* the associated users (IPsec stack, MIPv6 module) are notified (on both sides). I am considering that MIPv6 is used to cover all cases.=20 =2D address of the IKE GW on the remote side =2D the address of the HA used by the client =2D the remote address of currently negotiated transport mode SA protecting MIPv6 signaling=20 =2D endpoints of negotiated tunnel mode SA protecting data traffic if any I imagine that they will be set to the new IP. AFAICT, if the negotiation was triggered by a BU, there will be a mismatch between the triggering packet and the new destination. > When this mechanism is used with Mobile IPv6, a mobile node's > security associations with its home agent may expire while it still > has a valid binding cache entry at the home agent. In this case, the > mobile node MUST NOT use an anycast address as the destination > address in the IKE_SA_INIT exchange to setup new security > associations. It MUST try to setup security associations with its > existing home agent. How does the MN knows the address is anycast? Here, I do not understand well the MIPv6 scenario. Can you clarify what you mean. > Section 4. Perhaps the previous point regarding interactions of MIPv6 clients with IKE daemons that are part of an anycast domain belong here. You should probably add some clear statements regarding the use of anycast addresses for IKE daemon for MIPv6 clients. More precisely, what are the conditions for a MIPv6 client to be configured with an anycast address (or a name resolving to an anycast address) for the IKE daemon of its HA. Can you tell me if I am wrong on this summary: you expect that a MIPv6 client can be configured with an anycast address (or a name resolving to an anycast address) for the IKE daemon of its HA if: =2D its local IKE Daemon support the Redirect =2D it is redirected to a non-anycast unicast address when it connects the first time=20 =2D it uses the address for all future connections to the remote IKE daemon while it is registered with its HA. > 5. I skipped it at the moment but will review in a future version of the draft.=20 > 6. Security Considerations ok. Cheers, a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFILVdsAlWVfAR6UCYRAnsFAJ9qcSg0Y9aLLn89CDE+ikvogyNUNQCfehu1 okqMo8QM7WgtTDcABQ8ptpM= =LUYf -----END PGP SIGNATURE----- --=-=-=-- --===============0031460654== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0031460654==-- From mext-bounces@ietf.org Fri May 16 05:51:25 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8148428C1AA; Fri, 16 May 2008 05:51:25 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EA5C28C1AA for ; Fri, 16 May 2008 05:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[AWL=-1.190, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeC0uWgFeOh4 for ; Fri, 16 May 2008 05:51:23 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 74C3D28C1A7 for ; Fri, 16 May 2008 05:51:22 -0700 (PDT) Received: (qmail invoked by alias); 16 May 2008 12:51:17 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp012) with SMTP; 16 May 2008 14:51:17 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19JoOxbqKNJtNapy0ObQmed60G9H1AXvdN7t0AVWr 01N/XG3diPHgxD Message-ID: <482D8344.8040307@gmx.net> Date: Fri, 16 May 2008 15:51:16 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: mext@ietf.org X-Y-GMX-Trusted: 0 Subject: [MEXT] draft-ietf-mext-aaa-ha-goals X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I read through the draft and think it is OK. Ciao Hannes _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri May 16 15:32:07 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56A603A68D4; Fri, 16 May 2008 15:32:07 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65E753A67ED for ; Fri, 16 May 2008 15:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIiwHjGYFEVt for ; Fri, 16 May 2008 15:32:04 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 0C8783A68DE for ; Fri, 16 May 2008 15:32:03 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4GMVmqv001964; Fri, 16 May 2008 17:31:51 -0500 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 17 May 2008 01:31:48 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 May 2008 17:31:46 -0500 Received: from 10.241.59.89 ([10.241.59.89]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 16 May 2008 22:31:46 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 16 May 2008 17:32:16 -0500 From: Basavaraj Patil To: ext Ahmad Muhanna , Brian Haley , Behcet Sarikaya Message-ID: Thread-Topic: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-00.txt Thread-Index: AcisZgajIsShiz9NSrC1XTquiR0ADwAM8ZNgAsK5Iu0= In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 16 May 2008 22:31:46.0503 (UTC) FILETIME=[9FE2F570:01C8B7A4] X-Nokia-AV: Clean Cc: mext@ietf.org Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org FWIW, I think Ahmad does have a point about whether to define a new MH type message for revocation or to reuse the gen-notification message. It is possible to consider revocation as merely a notification to the MN or the MAG in the case of PMIP6 in which case the gen-notification approach is sufficient. However I think that the revocation of the binding is more than mere notification. IMO, gen-notification is for purposes such as informing the MN about other non-critical things. Revocation is tied to the mobility of the MN and hence would be used to trigger possibly other actions (such as recharging a prepaid account or connecting the MN to a provisioning site etc.). So it makes sense to define revocation messages via new MH type. While we can utilize the gen-notification messages to solve the revocation problem as I do not see a major technical issue with it, it may not be the most elegant one and this difference of views is more semantic than syntactic. -Raj On 5/2/08 4:24 PM, "ext Ahmad Muhanna" wrote: > Hi Brian, > Please see comment inline. > > Regards, > Ahmad > > >> Action:draft-muhanna-mext-binding-revocation-00.txt >> >> Hi Behcet, >> >> Behcet Sarikaya wrote: >>> Hi Brian, >>> I agree that generic notifications can support binding >> revocation. >>> My concern is that there is no use case clearly defined in >> the generic >>> notifications draft. As such it is too "generic". On the other hand >>> binding revocation is more clearly defined, in fact it is >> (should be) >>> part of BU/BA exchange semantics. >> >> I'll let WG consensus decide if revocation should define two >> new MH types or use gen-notification. >> >>> For example, can you say that generic notifications can >> be used for >>> handover? >> >> Well, if I wrote the Generic Notification draft first, HA >> Switch could have maybe just been a mobility option. > > [Ahmad] > It actually depends on the scope, for example, if we go a little back in > time and according to the "request/Reply" scope for the Generic > Notification Message that was mentioned earlier: may be; we could have > defined MIP6 BU/BA as Generic Notification Messages and closed all the > books and saved ourselves a lot of time and resources. > > Cheers! > >> >> -Brian >> >>> ----- Original Message ---- >>> From: Brian Haley >>> To: Vijay Devarapallli >>> Cc: mext >>> Sent: Wednesday, April 30, 2008 1:48:02 PM >>> Subject: Re: [MEXT] FW: I-D >>> Action:draft-muhanna-mext-binding-revocation-00.txt >>> >>> Hi Vijay, >>> >>> I've been talking with Ahmad and Sri about this off-line and we're >>> trying to come to an agreement over some of the text in >>> gen-notification to more easily support the revocation draft. >>> Hopefully an update will be agreeable to everyone, but I wouldn't >>> necessarily hold-up the current revocation draft for it. >> That's my thoughts at least. >>> >>> -Brian >>> >>> Vijay Devarapallli wrote: >>>> Hi Ahmad and others, >>>> >>>> We previously had a discussion on this draft on the MIP6 mailing >>> list > and it was agreed that the binding revocation >> message will be >>> a > sub-type in the Generic Notification Message. >>>> >>> >> http://www.ietf.org/internet-drafts/draft-haley-mext-generic-notificat >>> ion-message-00.txt >>>> >>>> We would need to modify the generic notification message >> to include >>> a > new 'subtype' field. We had discussed this in the past >> and made >>> no > progress. We can start with the following values > > 0 - >>> Reserved, not used > 1 - Notification message indicated by >> Mobility >>> Options > 2 - Binding Revocation Indication > 3 - Binding >> Revocation >>> Acknowledgement > 4-255 reserved > > The Generic Notification >>> message draft is quite simple and shouldn't > take too long to >>> standardize. It would be a good idea to use the > Generic >>> Notification message as much as > possible when you have >> something to >>> notify to either the mobile node > or the home agent. Otherwise we >>> might end up with a proliferation of > notification >> messages using up >>> a lot of mobility header message types. >>>> >>>> Vijay >>>> >>>> On Tue, Apr 29, 2008 at 6:32 PM, Ahmad Muhanna >> >> > wrote: >>>>> Hello All, >>>>> >>>>> Please find the latest Binding Revocation for IPv6 >> Mobility draft >>> at the >> below link. >>>>> We highly value your review and comments! >>>>> >>>>> Many Thanks in advance! >>>>> >>>>> Best Regards, >>>>> Ahmad >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: i-d-announce-bounces@ietf.org >>> >>>>> [mailto:i-d-announce-bounces@ietf.org >>> ] On Behalf Of >> >>> Internet-Drafts@ietf.org >>>> Sent: >>> Tuesday, April 29, 2008 8:30 PM >> To: i-d-announce@ietf.org >>> >> Subject: I-D >>> Action:draft-muhanna-mext-binding-revocation-00.txt >>>>> >>>>> A New Internet-Draft is available from the on-line >>> Internet-Drafts >> directories. >>>>> >>>>> Title : Binding Revocation for IPv6 Mobility >>>>> Author(s) : A. Muhanna, et al. >>>>> Filename : >> draft-muhanna-mext-binding-revocation-00.txt >>>>> Pages : 32 >>>>> Date : 2008-04-29 >>>>> >>>>> This document defines the revocation semantics for >> terminating a >>> mobile >> node's mobility session and associated >> resources. These >>> semantics are >> generic enough and can be used by >> mobility entities >>> in the case of >> Client Mobile IPv6 and its extensions. This >>> mechanism allows the >> mobility entity which initiates the >>> revocation procedure to request its >> corresponding one to >>> terminate either one, multiple or all specified >> >> binding cache entries. >>>>> >>>>> A URL for this Internet-Draft is: >>>>> >>> >> http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocat >>> io >>>>> n-00.txt >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> Below is the data which will enable a MIME compliant >> mail reader >>>>> implementation to automatically retrieve the ASCII >> version of the >>>>> Internet-Draft. >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>>> >>>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat May 17 00:07:46 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85EC628C1E0; Sat, 17 May 2008 00:07:46 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA6C628C1E0 for ; Sat, 17 May 2008 00:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vD0l549ghoxq for ; Sat, 17 May 2008 00:07:39 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 286AD3A6784 for ; Sat, 17 May 2008 00:07:37 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id m4H77RAH013361; Sat, 17 May 2008 16:07:27 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb3) with ESMTP id m4H77R415037; Sat, 17 May 2008 16:07:27 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili04) with ESMTP id m4H77PK15002; Sat, 17 May 2008 16:07:25 +0900 (JST) Received: from NW-Sephiroth ([10.239.16.101]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 May 2008 15:06:34 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Sat, 17 May 2008 15:06:30 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Sat, 17 May 2008 15:06:30 +0800 From: "Benjamin Lim" To: "'Ahmad Muhanna'" Date: Sat, 17 May 2008 15:06:27 +0800 Message-ID: <000001c8b7ec$87669130$6510ef0a@psl.local> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciuWf2Y1JeerkUGQ46fWXJo4+sPHAJi0ddQ X-OriginalArrivalTime: 17 May 2008 07:06:34.0626 (UTC) FILETIME=[8AA47E20:01C8B7EC] Cc: mext@ietf.org Subject: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad, I snipped sections from the draft to reflect some comments (mostly editorial). Regards, Benjamin Lim ---------- 3.1. Binding Revocation Protocol ... On the other hand, the mobility access gateway usually sends a de- registration message by sending a Proxy BU with a lifetime of zero to indicate to the local mobility anchor of the termination of the PMIPv6 mobile node binding registration. In this case, the mobility access gateway include the MN home network prefix option and the MN-ID option as per [2] in order for the local mobility anchor to identify the mobile node PMIPv6 binding. However, in the case when the mobility access gateway communicates a bulk termination of PMIPv6 sessions, the mobility access gateway sends a BRI message with the G bit set and includes the mobility access gateway identity in the MN-ID option. When the local mobility anchor receives such BRI message, it ensures that the mobility access gateway is authorized to send such bulk termination message and then process the BRI message accordingly. If the local mobility anchor processes the BRI message successfully and the (A) bit is set in the BRI, the local mobility anchor responds to the mobile access gateway by sending a BRA message. Aditionally, the initiator of the binding revocation ^^^^^^^^^ [Ben] Additionally procedure include an indication in the Revocation Trigger field to indicate to the receiving node the cause for the revocation procedure. ... 3.3.1. Termination of Multiple Care-of Addresses Bindings In the case of multiple care-of addresses, the home agent maintains different binding for each pair of care-of address and home address. These bindings are also indexed and identified during the mobile node registration using a new Binding ID mobility option [5]. In this case, the home agent may revoke any binding, more than one binding, or all of the bindings for the same mobile node home address. [Ben] Suggest reword above sentence to "In this case, the home agent may revoke either one or multiple of the mobile node's binding associated to the mobile node's home address." ... Figure 2: Home Agent Revokes MN's Specific Registered Care-of Addresses Bindings [Ben] What is 'Cause' specified in the BRA from MN to HA? ... 3.4.1. Local Mobility Anchor Revokes A PMIPv6 Binding The local mobility anchor may send a BRI message to the mobile access gateway, hosting a specific proxy mobile IPv6 session, with the appropriate value in the revocation trigger field to indicate that the mobile node binding has been terminated and the mobile access gateway can clean up the applicable resources. When the mobile access gateway receives a BRI message, the MAG identify the respected ^^^^^^^ [Ben] respective binding and if the A bit was set in the received BRI message, the MAG sends a BRA message to the LMA. In this case, the MAG could send a Router Advertisement message to the MN with the home network prefix lifetime is set to zero. As an example, Figure 3, illustrates the message sequence for revoking a mobile node binding at the source MAG during the MN inter- MAG handoff. During the inter-MAG handoff, the mobile node moves from the source MAG to the target MAG. The target MAG sends a PBU with the new care-of-address to the LMA to update the mobile node point of attachement. Since the MN binding at the LMA points to the ^^^^^^^^^^ [Ben] attachment source MAG and upon receiving the PBU from the target MAG, LMA updates the MN BCE and send a PBA to the target MAG. LMA can send a BRI message with the appropriate revocation trigger value, e.g. inter-MAG handoff indication, to the source MAG in order to clean up the applicable resources reserved for the specified MN. The MAG acknowledges the BRI message by sending a BRA message to indicate the success or failure of the termination of the mobile node binding. The process identified above can also be used by the LMA in scenarios other than the inter-MAG handoff with the propoer revocation trigger ^^^^^^^ [Ben] proper value to indicate to the peer MAG that a specific proxy mobile IPv6 binding or bindings have been revoked. Figure 3: LMA Revokes a MN Registration During Inter-MAG Handoff [Ben] What is 'Cause' specified in the BRA from sMAG to LMA? ... 3.4.3. Mobile Access Gateway Revoke Bulk PMIPv6 Bindings The mobile access gateway send a de-registration PBU with lifetime of zero as described in [2] to indicated to the LMA the termination of a mobile node registration binding. However, the mobile access gateway sends a BRI message with the G bit is set to indicate that all mobility sessions which are registered at the LMA and attached to the MAG are being revoked as in Section 9.2.1. When the LMA receives a BRI message with the G bit is set from a specified MAG, the LMA checks if the MAG is authorized to use global revocations and responds with the approporiate status code by sending a BRA message ^^^^^^^^^^ [Ben] appropriate as in Section 8.2.2. ... 5.1. Binding Revocation Indication Message ... Binding ID mobility option [5]. This option is mandatory if the sending mobility entity request to terminate one binding of a multi care-of addresses bindings for the same mobile node. [Ben] Suggest reword above sentence to "This option is mandatory if the sending mobility entity request to terminate a multiple care-of address registered binding of a mobile node." The sending Mobility entity may include more than one of these mobility options. ... 6.1. Sending Binding Revocation Messages When a mobility entity initiate the binding revocation process by sending a Binding Revocation Indication, the initiator MUST construct the BRI message as described in Section 5.1. In the BRI message, the initiator MUST set the Sequence Number field to the next sequence number available for Binding Revocation. Since sending Binding Revocation Indication messages is not done on a regular basis, a 16 bit sequence number field is large enough to allow the initiator to match the Binding Revocation Acknowledgement to the outstanding Binding Revocation Indication with (A) bit set using the seqeuence ^^^^^^^^ [Ben] sequence number field only. ... 6.3. Retransmission of Binding Revocation Indication If the sending mobility entity does not receive a Binding Revocation Acknowledgement in response to the outstanding Binding Revocation Indication before the MINDelayBRIs timer expires, the mobility entity, e.g. LMA, may retransmit the same BRI message upto the ^^^^ [Ben] up to BRIMaxRetriesNumber as defined in Section 11. If the revoking mobility entity does not receive a BRA message after the maximum number of retrasmits have been sent, the revoking mobility entity can ^^^^^^^^^^^^^^^^^^^ [Ben] retransmissions (remove "have been sent" as transmit implies sending) clean the mobile node binding cache and all resources associated with this binding. The revoking mobility entity may log the event. ... 7.2. Receiving Binding Revocation Acknowledgement ... If the Status field indicates any value other than success, the home agent SHOULD examine any mobility options included in the Binding Revocation Acknowledgement. The home agent MAY log the approriate event to reflect the status of the received BRA. ^^^^^^^^ [Ben] appropriate ... 8.1.1. Sending Binding Revocation Indication ... When the local mobility anchor needs to revoke all mobile nodes proxy BCE that belong to a specific realm, e.g. @companyabc.com, and are registered with the local mobility anchor and hosted at the mobile access gateway, [Ben] Suggest reword the above to "When the local mobility anchor needs to revoke all currently registered mobile nodes proxy BCE that belong to a specific realm (e.g. @companyabc.com) at a particular mobile access gateway," the local mobility anchor MUST set the Global (G) bit and the value of the Revocation Trigger field to Local Policy. In this case, the local mobility anchor MUST include a mobility option to identify the impacted bindings, e.g. MN-ID option with a wildcard NAI, e.g. *@companyabc.com, to identify all the mobile nodes BCEs that need to be removed. [Ben] Is there such a thing as a wildcard NAI? Why can't the LMA just include every single affect MN-ID as an option in the BRI? ... 8.2.1. Receiving Binding Revocation Indication ... The Revocation Trigger field value in the received Binding Revocation Indication could be used by the local mobility anchor to log an event or update some local parameters which tracks the satate of the peer ^^^^ [Ben] state mobile access gateway. ... 9.1.2. Sending Binding Revocation Acknowledgement ... When the mobile access gateway receive a valid Binding Revocation ^^^^^^ [Ben] receives Indication with the (A) bit is set and after processing the BRI message, the mobile access gteway sends a packet to the local ^^^^^^ [Ben] gateway mobility anchor containing a Binding Revocation Acknowledgement according to the procedure in Section 6.1 and the following: ... 9.2.1. Sending Binding Revocation Indication ... The mobile access gateway send a Binding Revocation Indication when it needs to use global revocation, i.e. when the G bit is set. In this case when an event occurs which requires the mobile access gateway to inform the local mobility anchor to terminate all mobile nodes bindings that are registered at the local mobility anchor and the mobile access gateway, the mobile access gateway send a Binding Revocation Inidcation message following Section 6.1 and the ^^^^^^^^ [Ben] Indication follwoing: ^^^^^^^ [Ben] following: ... 9.2.2. Receiving Binding Revocation Acknowledgement ... If the Status field indicates (Global Revocation NOT Authorized), the mobile access gateway is not authorized to participate in a Per-Peer Global Revocation. The mobile access gateway SHOULD NOT retry sending a Binding Revocation Inidication with the Global (G) ^^^^^^^^ [Ben] Indication bit is set to the same local mobility agent. The mobile access gateway should raise an alarm or log an event to indicate this rejection. ... 10.1. Receiving Binding Revocation Indication ... If the mobile node has registered multiple care-of addresses with its home agent, the mobile node MUST verify which binding is being revoked by examining the content of the BRI message. If the mobile node received a Binding Revocation Indication with a single or more than one BID options and its home adress is in the Home Address option, [Ben] Suggest reword above to "If the mobile node receives a Binding Revocation Indication containing either a single or multiple BID options that is associated to its home address specified in the Home Address option," the mobile node MUST consider its bindings identified in the Binding ID options are being revoked. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sat May 17 00:42:57 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A9463A6A05; Sat, 17 May 2008 00:42:57 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78B283A6A05 for ; Sat, 17 May 2008 00:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHOckoFiBEKq for ; Sat, 17 May 2008 00:42:54 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id ED4C43A69ED for ; Sat, 17 May 2008 00:42:53 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id m4H7gmMe018791; Sat, 17 May 2008 16:42:48 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb3) with ESMTP id m4H7gm423946; Sat, 17 May 2008 16:42:48 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili02) with ESMTP id m4H7gml10490; Sat, 17 May 2008 16:42:48 +0900 (JST) Received: from NW-Sephiroth ([10.239.16.101]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 May 2008 15:41:55 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Sat, 17 May 2008 15:41:51 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Sat, 17 May 2008 15:41:51 +0800 From: "Benjamin Lim" To: "'Ahmad Muhanna'" Date: Sat, 17 May 2008 15:41:48 +0800 Message-ID: <000601c8b7f1$77b54970$6510ef0a@psl.local> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciuWf2Y1JeerkUGQ46fWXJo4+sPHAJi0ddQAAHn2VAAAAgmQAAAcU1AAAA/eVAAAC0dUAAAOEgA X-OriginalArrivalTime: 17 May 2008 07:41:55.0304 (UTC) FILETIME=[7AAA4680:01C8B7F1] Cc: mext@ietf.org Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-01.txt (Resend) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Sorry due to some formatting error in my client. I resend my previous mail. > -----Original Message----- > Hi Ahmad, > > I snipped sections from the draft to reflect some comments (mostly > editorial). > > Regards, > Benjamin Lim > > ---------- > > 3.1. Binding Revocation Protocol > > ... > On the other hand, the mobility access gateway usually sends a de- > registration message by sending a Proxy BU with a lifetime of zero to > indicate to the local mobility anchor of the termination of the > PMIPv6 mobile node binding registration. In this case, the mobility > access gateway include the MN home network prefix option and the MN-ID > option as per [2] in order for the local mobility anchor to identify > the mobile node > PMIPv6 binding. However, in the case when the mobility access gateway > communicates a bulk termination of PMIPv6 sessions, the mobility > access gateway sends a BRI message with the G bit set and includes the > mobility access gateway identity in the MN-ID option. When the local > mobility anchor receives such BRI message, it ensures that the > mobility access gateway is authorized to send such bulk termination > message and then process the BRI message accordingly. If the local > mobility anchor processes the BRI message successfully and the (A) bit > is set in the BRI, the local mobility anchor responds to the mobile > access gateway by sending a BRA message. > Aditionally, the initiator of the binding revocation [Ben] s / Aditionally/ Additionally > > procedure include an indication in the Revocation Trigger field to > indicate to the receiving node the cause for the revocation procedure. > > ... > > 3.3.1. Termination of Multiple Care-of Addresses Bindings > > In the case of multiple care-of addresses, the home agent maintains > different binding for each pair of care-of address and home address. > These bindings are also indexed and identified during the mobile node > registration using a new Binding ID mobility option [5]. In this > case, the home agent may revoke any binding, more than one binding, or > all of the bindings for the same mobile node home address. > [Ben] Suggest reword above sentence to "In this case, the home agent may revoke either one or multiple of the mobile node's binding associated to the mobile node's home address." > > ... > > Figure 2: Home Agent Revokes MN's Specific Registered Care-of > Addresses Bindings > [Ben] What is 'Cause' specified in the BRA from MN to HA? > > ... > > 3.4.1. Local Mobility Anchor Revokes A PMIPv6 Binding > > The local mobility anchor may send a BRI message to the mobile access > gateway, hosting a specific proxy mobile IPv6 session, with the > appropriate value in the revocation trigger field to indicate that the > mobile node binding has been terminated and the mobile access gateway > can clean up the applicable resources. When the mobile access gateway > receives a BRI message, the MAG identify the respected [Ben] s /respected /respective > > binding and if the A bit was set in the received BRI message, the MAG > sends a BRA message to the LMA. In this case, the MAG could send a > Router Advertisement message to the MN with the home network prefix > lifetime is set to zero. > > As an example, Figure 3, illustrates the message sequence for revoking > a mobile node binding at the source MAG during the MN inter- MAG > handoff. > During the inter-MAG handoff, the mobile node moves from the source > MAG to the target MAG. The target MAG sends a PBU with the new > care-of-address to the LMA to update the mobile node point of > attachement. Since the MN binding at the LMA [Ben] s /attachement / attachment > > points to the > source MAG and upon receiving the PBU from the target MAG, LMA updates > the MN BCE and send a PBA to the target MAG. LMA can send a BRI > message with the appropriate revocation trigger value, e.g. > inter-MAG handoff indication, to the source MAG in order to clean up > the applicable resources reserved for the specified MN. The MAG > acknowledges the BRI message by sending a BRA message to indicate the > success or failure of the termination of the mobile node binding. > > The process identified above can also be used by the LMA in scenarios > other than the inter-MAG handoff with the propoer [Ben] s / propoer / proper > > revocation trigger > value to indicate to the peer MAG that a specific proxy mobile IPv6 > binding or bindings have been revoked. > > Figure 3: LMA Revokes a MN Registration During Inter-MAG Handoff > [Ben] What is 'Cause' specified in the BRA from sMAG to LMA? > > ... > > 3.4.3. Mobile Access Gateway Revoke Bulk PMIPv6 Bindings > > The mobile access gateway send a de-registration PBU with lifetime of > zero as described in [2] to indicated to the LMA the termination of a > mobile node registration binding. > However, the mobile access gateway sends a BRI message with the G bit > is set to indicate that all mobility sessions which are registered at > the LMA and attached to the MAG are being revoked as in Section 9.2.1. > When the LMA receives a BRI message with the G bit is set from a > specified MAG, the LMA checks if the MAG is authorized to use global > revocations and responds with the approporiate status code by sending [Ben] s/ approporiate / appropriate > > a BRA message as in Section 8.2.2. > > ... > > 5.1. Binding Revocation Indication Message > > ... > Binding ID mobility option [5]. This option is mandatory if the > sending mobility entity request to terminate one binding of a multi > care-of addresses bindings for the same mobile node. > [Ben] Suggest reword above sentence to "This option is mandatory if the sending mobility entity request to terminate a multiple care-of address registered binding of a mobile node." > > The sending Mobility entity may include more than one of these > mobility options. > > ... > > 6.1. Sending Binding Revocation Messages > > When a mobility entity initiate the binding revocation process by > sending a Binding Revocation Indication, the initiator MUST construct > the BRI message as described in Section 5.1. In the BRI message, the > initiator MUST set the Sequence Number field to the next sequence > number available for Binding Revocation. Since sending Binding > Revocation Indication messages is not done on a regular basis, a 16 > bit sequence number field is large enough to allow the initiator to > match the Binding Revocation Acknowledgement to the outstanding > Binding Revocation Indication with (A) bit set using the seqeuence [Ben] s / seqeuence / sequence > > number field only. > > ... > > 6.3. Retransmission of Binding Revocation Indication > > If the sending mobility entity does not receive a Binding Revocation > Acknowledgement in response to the outstanding Binding Revocation > Indication before the MINDelayBRIs timer expires, the mobility entity, > e.g. LMA, may retransmit the same BRI message upto the [Ben] s/ upto / up to > > BRIMaxRetriesNumber as defined in Section 11. If the revoking > mobility entity does not receive a BRA message after the maximum > number of retrasmits have been sent, the revoking [Ben] s/ retrasmits have been sent / retransmissions > > mobility entity can > clean the mobile node binding cache and all resources associated with > this binding. The revoking mobility entity may log the event. > > ... > > 7.2. Receiving Binding Revocation Acknowledgement > > ... > > If the Status field indicates any value other than success, the home > agent SHOULD examine any mobility options included in the Binding > Revocation Acknowledgement. The home agent MAY log the approriate [Ben] s / approriate / appropriate > > event to reflect the status of the received BRA. > > ... > > 8.1.1. Sending Binding Revocation Indication > > ... > > When the local mobility anchor needs to revoke all mobile nodes proxy > BCE that belong to a specific realm, e.g. > @companyabc.com, and are registered with the local mobility anchor and > hosted at the mobile access gateway, > [Ben] Suggest reword the above to "When the local mobility anchor needs to revoke all currently registered mobile nodes proxy BCE that belong to a specific realm (e.g.@companyabc.com) at a particular mobile access gateway," > > the local mobility anchor MUST set the Global (G) bit and the value of > the Revocation Trigger field to Local Policy. In this case, the local > mobility anchor MUST include a mobility option to identify the > impacted bindings, e.g. MN-ID option with a wildcard NAI, e.g. > *@companyabc.com, to identify all the mobile nodes BCEs that need to > be removed. > [Ben] Is there such a thing as a wildcard NAI? Why can't the LMA just include every single affect MN-ID as an option in the BRI? > > ... > > 8.2.1. Receiving Binding Revocation Indication > > ... > > The Revocation Trigger field value in the received Binding Revocation > Indication could be used by the local mobility anchor to log an event > or update some local parameters which tracks the satate of the peer [Ben] s / satate / state > > mobile access gateway. > > ... > > 9.1.2. Sending Binding Revocation Acknowledgement > > ... > > When the mobile access gateway receive a valid Binding Revocation [Ben] s / receive / receives > > Indication with the (A) bit is set and after processing the BRI > message, the mobile access gteway sends a packet to the local [Ben] s/ gteway / gateway > > mobility anchor containing a Binding Revocation Acknowledgement > according to the procedure in Section 6.1 and the following: > > ... > > 9.2.1. Sending Binding Revocation Indication > > ... > > The mobile access gateway send a Binding Revocation Indication when it > needs to use global revocation, i.e. when the G bit is set. In this > case when an event occurs which requires the mobile access gateway to > inform the local mobility anchor to terminate all mobile nodes > bindings that are registered at the local mobility anchor and the > mobile access gateway, the mobile access gateway send a Binding > Revocation Inidcation message following Section 6.1 and the [Ben] s / Inidcation / Indication > follwoing: [Ben] s / follwoing / following: > > ... > > 9.2.2. Receiving Binding Revocation Acknowledgement > > ... > > If the Status field indicates (Global Revocation NOT Authorized), the > mobile access gateway is not authorized to participate in a Per-Peer > Global Revocation. The mobile access gateway SHOULD NOT retry sending > a Binding Revocation Inidication with the Global (G) [Ben] s / Inidication / Indication > > bit is set to the same local mobility agent. The mobile access > gateway should raise an alarm or log an event to indicate this > rejection. > > ... > > 10.1. Receiving Binding Revocation Indication > > ... > > If the mobile node has registered multiple care-of addresses with its > home agent, the mobile node MUST verify which binding is being revoked > by examining the content of the BRI message. If the mobile node > received a Binding Revocation Indication with a single or more than > one BID options and its home adress is in the Home Address option, > [Ben] Suggest reword above to "If the mobile node receives a Binding Revocation Indication containing either a single or multiple BID options that is associated to its home address specified in the Home Address option," > > the mobile node MUST consider its bindings identified in the Binding > ID options are being revoked. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun May 18 08:43:33 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E8D13A6C16; Sun, 18 May 2008 08:43:33 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C57503A67AC for ; Sun, 18 May 2008 08:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[RCVD_BAD_ID=2.088, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dppFXCZSlIf for ; Sun, 18 May 2008 08:43:31 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 0B2DF3A6C16 for ; Sun, 18 May 2008 08:43:30 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (91.45.217.87.dynamic.jazztel.es [87.217.45.91])by smtp02.uc3m.es (Postfix) with ESMTP id 8AF6139CA4A;Sun, 18 May 2008 17:43:28 +0200 (CEST) Message-ID: <48304E9F.9080500@it.uc3m.es> Date: Sun, 18 May 2008 17:43:27 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Hannes Tschofenig References: <482D8344.8040307@gmx.net> In-Reply-To: <482D8344.8040307@gmx.net> X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-10.6085 TC:1F TRN:12 TV:5.5.1026(15918.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: mext@ietf.org Subject: Re: [MEXT] draft-ietf-mext-aaa-ha-goals X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Great, thanks, we will forward this to the IESG shortly regards, marcelo Hannes Tschofenig escribi=F3: > I read through the draft and think it is OK. > > Ciao > Hannes > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun May 18 08:45:09 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8326628C4F2; Sun, 18 May 2008 08:45:09 -0700 (PDT) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6316528C481; Sun, 18 May 2008 08:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080518154501.6316528C481@core3.amsl.com> Date: Sun, 18 May 2008 08:45:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-flow-binding-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Flow Bindings in Mobile IPv6 and Nemo Basic Support Author(s) : H. Soliman, et al. Filename : draft-ietf-mext-flow-binding-00.txt Pages : 32 Date : 2008-05-16 This document introduces extensions to Mobile IPv6 [1] and Nemo Basic Support [2] that allow nodes to bind one or more flows to a care-of address. These extensions allow multihomed nodes to take full advantage of the different properties associated with each of their interfaces. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-flow-binding-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-mext-flow-binding-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-18084434.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --NextPart-- From c.price@seminoletransportation.com Sun May 18 09:53:21 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B050A3A6C51; Sun, 18 May 2008 09:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -69.651 X-Spam-Level: X-Spam-Status: No, score=-69.651 tagged_above=-999 required=5 tests=[FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_DHCP=1.52, HELO_DYNAMIC_IPADDR=2.935, RCVD_IN_BL_SPAMCOP_NET=2.188, RCVD_IN_PBL=0.509, RCVD_IN_SORBS_DUL=1.615, RCVD_IN_XBL=2.896, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nkx0xESFu-9d; Sun, 18 May 2008 09:53:20 -0700 (PDT) Received: from cable200-116-144-27.epm.net.co (cable200-116-144-27.epm.net.co [200.116.144.27]) by core3.amsl.com (Postfix) with SMTP id 2D08D28C4EF; Sun, 18 May 2008 09:53:11 -0700 (PDT) X-Originating-IP: 19.6.151.143 by smtp.200.116.144.27; Sun, 18 May 2008 12:53:12 -0500 Message-ID: From: "Hugo Spears" Reply-To: "Hugo Spears" To: msec-archive@ietf.org Subject: New replica watches delivered fast Date: Sun, 18 May 2008 12:53:12 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit With hundreds of models to choose from, rock bottom prices and the best customer service in the whole wide web, Prestige Replicas has become the standard by which replica watches stores are measured. It's no wonder every day hundreds of new visitors flock to this website in search of the ultimate (yet affordable) gift: a replica Breitling watch. And every one of these visitors has been exceedingly delighted with the quality of their new Breitling timepiece. http://wavotyny37041.blogspot.com/ Prestige Replicas is a well-established online store that has made the purchase of a replica timepiece easy, safe and affordable. They take pride in the exceptional quality watches they offer, and will do whatever it takes to provide you with a distinctive replica timepiece like the one you've always wanted. That's why they now offer an extra 15% discount in the purchase of two watches. Just when you thought Prestige Replicas couldn't get any better, they have improved the perfect watch shopping experience! http://wavotyny37041.blogspot.com/ No virus found in this outgoing message Checked by PC Tools AntiVirus (4.0.0.26 - 10.072.012). http://www.pctools.com/free-antivirus/ From c700a8c0@pov.com.pl Sun May 18 09:58:36 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08C1C3A6A4F; Sun, 18 May 2008 09:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -59.893 X-Spam-Level: X-Spam-Status: No, score=-59.893 tagged_above=-999 required=5 tests=[DNS_FROM_RFC_BOGUSMX=2.125, FB_QUALITY_REPLICA=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_DHCP=1.52, HELO_EQ_DSL=1.129, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.509, RCVD_IN_SORBS_DUL=1.615, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OUf2MUpdvTW; Sun, 18 May 2008 09:58:35 -0700 (PDT) Received: from adsl-72-50-13-202.prtc.net (adsl-72-50-13-202.prtc.net [72.50.13.202]) by core3.amsl.com (Postfix) with SMTP id 05DE63A67E2; Sun, 18 May 2008 09:58:12 -0700 (PDT) X-Originating-IP: 80.222.8.87 by smtp.72.50.13.202; Sun, 18 May 2008 12:58:12 -0500 Message-ID: From: "Francisco Story" Reply-To: "Francisco Story" To: multimob@ietf.org Subject: Replica watches make great gifts Date: Sun, 18 May 2008 12:58:12 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Prestige Replicas is now bigger and better than ever before! I'm sure you're familiar with this popular replica store, so I'm glad to announce that Prestige Replicas has been completely redesigned and now offers not only the highest quality replica watches but also handbags and jewelry! In addition, they're running a 15% special these days when you buy two watches! There's never been a better time to buy a replica watch, especially a Tag Heuer! With prices as low as $200, and the store unmatched privacy assurance guarantee, I'm sure you won't want to wait to get your superior quality Tag Heuer replica! http://vazupucu34030.blogspot.com/ From c0wz@c0wzftp.com Sun May 18 23:57:52 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF9573A685E; Sun, 18 May 2008 23:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.121 X-Spam-Level: X-Spam-Status: No, score=-11.121 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3AYkqz4ZAca; Sun, 18 May 2008 23:57:48 -0700 (PDT) Received: from bzq-79-176-123-137.red.bezeqint.net (bzq-79-176-123-137.red.bezeqint.net [79.176.123.137]) by core3.amsl.com (Postfix) with SMTP id 1F9903A69E1; Sun, 18 May 2008 23:57:18 -0700 (PDT) X-Originating-IP: 112.237.64.240 by smtp.79.176.123.137; Mon, 19 May 2008 02:57:19 -0500 Message-ID: From: "Ross Higgins" Reply-To: "Ross Higgins" To: msec-archive@ietf.org Subject: Get your watch now Date: Mon, 19 May 2008 02:57:19 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit With hundreds of models to choose from, rock bottom prices and the best customer service in the whole wide web, Prestige Replicas has become the standard by which replica watches stores are measured. It's no wonder every day hundreds of new visitors flock to this website in search of the ultimate (yet affordable) gift: a replica Breitling watch. And every one of these visitors has been exceedingly delighted with the quality of their new Breitling timepiece. http://pahucoxa70825.shheus.com/ Prestige Replicas is a well-established online store that has made the purchase of a replica timepiece easy, safe and affordable. They take pride in the exceptional quality watches they offer, and will do whatever it takes to provide you with a distinctive replica timepiece like the one you've always wanted. That's why they now offer an extra 15% discount in the purchase of two watches. Just when you thought Prestige Replicas couldn't get any better, they have improved the perfect watch shopping experience! http://pahucoxa70825.shheus.com/ From mext-bounces@ietf.org Mon May 19 05:30:10 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 618BF28C3AE; Mon, 19 May 2008 05:30:10 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D51C28C638 for ; Mon, 19 May 2008 05:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUzIFA15VclU for ; Mon, 19 May 2008 05:30:05 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 293BE3A6824 for ; Mon, 19 May 2008 05:30:05 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 43F781986D8; Mon, 19 May 2008 15:30:05 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 0B5781986D7; Mon, 19 May 2008 15:30:05 +0300 (EEST) Message-ID: <483172CC.8020403@piuha.net> Date: Mon, 19 May 2008 15:30:04 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14ubu (X11/20080502) MIME-Version: 1.0 To: Basavaraj Patil References: In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP Cc: draft-ietf-mip6-whyauthdataoption@tools.ietf.org, mext@ietf.org Subject: Re: [MEXT] re-review of draft-ietf-mip6-whyauthdataoption X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Any news on a new revision? Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon May 19 08:31:40 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBA0228C61C; Mon, 19 May 2008 08:31:40 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9040128C4D2 for ; Mon, 19 May 2008 08:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1HKtUhN4C5A for ; Mon, 19 May 2008 08:31:38 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 779DC28C2E7 for ; Mon, 19 May 2008 08:31:38 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4JFVHje020801; Mon, 19 May 2008 18:31:32 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 May 2008 18:30:13 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 May 2008 10:30:01 -0500 Received: from 10.138.85.208 ([10.138.85.208]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Mon, 19 May 2008 15:30:00 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 19 May 2008 10:30:36 -0500 From: Basavaraj Patil To: ext Jari Arkko Message-ID: Thread-Topic: re-review of draft-ietf-mip6-whyauthdataoption Thread-Index: Aci5xUi7h01PkiW4Ed2QsgARJNUNiA== In-Reply-To: <483172CC.8020403@piuha.net> Mime-version: 1.0 X-OriginalArrivalTime: 19 May 2008 15:30:01.0290 (UTC) FILETIME=[340B22A0:01C8B9C5] X-Nokia-AV: Clean Cc: draft-ietf-mip6-whyauthdataoption@tools.ietf.org, mext@ietf.org Subject: Re: [MEXT] re-review of draft-ietf-mip6-whyauthdataoption X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I had sent you some comments earlier in response to your suggestions. Have not heard back from you and hence am holding off on publishing a new I-D. I can rev a new version in the next day or so. But can you please take a look at that earlier email? Let me know if you want me to resend it (I believe it was cced on the MEXT list). Thx. -Raj On 5/19/08 7:30 AM, "ext Jari Arkko" wrote: > Any news on a new revision? > > Jari > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon May 19 09:12:50 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C80E23A6D90; Mon, 19 May 2008 09:12:48 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0C0E3A6ABE for ; Mon, 19 May 2008 09:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXNURakpBhDc for ; Mon, 19 May 2008 09:12:08 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 2C96E3A6AE8 for ; Mon, 19 May 2008 09:12:01 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 6B5951986E3; Mon, 19 May 2008 19:12:01 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 06BA21986D7; Mon, 19 May 2008 19:12:00 +0300 (EEST) Message-ID: <4831A6D1.9030100@piuha.net> Date: Mon, 19 May 2008 19:12:01 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14ubu (X11/20080502) MIME-Version: 1.0 To: heejin.jang@samsung.com References: <1967984.510541210245761238.JavaMail.weblogic@epml15> In-Reply-To: <1967984.510541210245761238.JavaMail.weblogic@epml15> X-Virus-Scanned: ClamAV using ClamSMTP Cc: Alexandru Petrescu , "mext@ietf.org" Subject: [MEXT] hiopt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi all, I have reviewed this thread and re-reviewed the draft. While I sympathize with some of the questions Alex had, I see no technical reason to block the draft from being approved, and I see no support from the WG from doing this either. So I am now approving the document. However, as a re-read the draft, I also noticed two additional issues. The first issue is that Section 3 seems to be forgetting the case where DHCP server has no information about a particular home network. Due to this, I would like to make the following change: OLD: In a network where the NAS is not co- located with a DHCP relay nor a server, the server may not be provided with the home network information from the NAS, and thereby it may assign to a mobile node the home information which has been preconfigured by the administrator or which is acquired through a mechanism that is not described in this document. NEW: In a network where the NAS is not co- located with a DHCP relay nor a server, the server may not be provided with the home network information from the NAS, and thereby it may either fail to provide information, or provide home information which has been preconfigured by the administrator or which is acquired through a mechanism that is not described in this document. Secondly, Section 4.2 and 4.3 talk about how relays can provide information to servers. But I cannot see how the server knows which piece of information from the relay corresponds to what Home Information Option, in case there were multiple options with different home network names. I am a bit uncertain how to fix this, however. Perhaps it is necessary to allow suboption type 1 in relay agent options, too. Please suggest text, and I will place it in the RFC Editor note part of the tracker and approve it. (Or you can submit a new version with these fixes.) Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon May 19 11:45:38 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18D8F3A6B2A; Mon, 19 May 2008 11:45:38 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7C9E3A6B46 for ; Mon, 19 May 2008 11:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[AWL=0.669, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3B99htPmWSn for ; Mon, 19 May 2008 11:45:30 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 8959A3A69E0 for ; Mon, 19 May 2008 11:45:22 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 56E3E198713; Mon, 19 May 2008 21:45:22 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 015611986D9; Mon, 19 May 2008 21:45:21 +0300 (EEST) Message-ID: <4831CAC2.6030707@piuha.net> Date: Mon, 19 May 2008 21:45:22 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14ubu (X11/20080502) MIME-Version: 1.0 To: Basavaraj Patil References: In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP Cc: draft-ietf-mip6-whyauthdataoption@tools.ietf.org, mext@ietf.org Subject: Re: [MEXT] re-review of draft-ietf-mip6-whyauthdataoption X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Basavaraj, > I had sent you some comments earlier in response to your suggestions. Have > not heard back from you and hence am holding off on publishing a new I-D. > I can rev a new version in the next day or so. > > But can you please take a look at that earlier email? Let me know if you > want me to resend it (I believe it was cced on the MEXT list). > Sorry, I didn't respond because I was mostly OK with what you had said in the e-mail. Re-reading the mail now, there is one part that I disagree: the extra protocol argument and IPsec. As discussed at the time that the whyauthdataoption draft was first reviewed, I think you have enough good arguments to make your case. Don't weaken it by trying to add more arguments that are not quite as sound... Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon May 19 11:55:26 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E5C028C128; Mon, 19 May 2008 11:55:26 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5D3828C123 for ; Mon, 19 May 2008 11:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRSYObZwIUrn for ; Mon, 19 May 2008 11:55:24 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 194DA28C0FB for ; Mon, 19 May 2008 11:55:24 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4JItEHY027907; Mon, 19 May 2008 13:55:20 -0500 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 May 2008 21:55:16 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 May 2008 13:55:09 -0500 Received: from 10.138.85.208 ([10.138.85.208]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Mon, 19 May 2008 18:55:09 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 19 May 2008 13:55:45 -0500 From: Basavaraj Patil To: ext Jari Arkko Message-ID: Thread-Topic: re-review of draft-ietf-mip6-whyauthdataoption Thread-Index: Aci54fF3L9DdtyXVEd2TagARJNUNiA== In-Reply-To: <4831CAC2.6030707@piuha.net> Mime-version: 1.0 X-OriginalArrivalTime: 19 May 2008 18:55:09.0634 (UTC) FILETIME=[DC636220:01C8B9E1] X-Nokia-AV: Clean Cc: draft-ietf-mip6-whyauthdataoption@tools.ietf.org, mext@ietf.org Subject: Re: [MEXT] re-review of draft-ietf-mip6-whyauthdataoption X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Okay... Will revise the I-D and submit it. -Raj On 5/19/08 1:45 PM, "ext Jari Arkko" wrote: > Basavaraj, > >> I had sent you some comments earlier in response to your suggestions. Have >> not heard back from you and hence am holding off on publishing a new I-D. >> I can rev a new version in the next day or so. >> >> But can you please take a look at that earlier email? Let me know if you >> want me to resend it (I believe it was cced on the MEXT list). >> > Sorry, I didn't respond because I was mostly OK with what you had said > in the e-mail. Re-reading the mail now, there is one part that I > disagree: the extra protocol argument and IPsec. As discussed at the > time that the whyauthdataoption draft was first reviewed, I think you > have enough good arguments to make your case. Don't weaken it by trying > to add more arguments that are not quite as sound... > > Jari > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From c.paul@brinkmann-formenbau.de Mon May 19 13:22:48 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DA733A6883; Mon, 19 May 2008 13:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -66.407 X-Spam-Level: X-Spam-Status: No, score=-66.407 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_QUALITY_REPLICA=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, HELO_DYNAMIC_IPADDR=2.426, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjgQeRG4j4Re; Mon, 19 May 2008 13:22:47 -0700 (PDT) Received: from d83-186-12-93.cust.tele2.be (d83-186-12-93.cust.tele2.be [83.186.12.93]) by core3.amsl.com (Postfix) with SMTP id 37C6B3A68EB; Mon, 19 May 2008 13:22:01 -0700 (PDT) X-Originating-IP: 204.100.112.255 by smtp.83.186.12.93; Mon, 19 May 2008 16:22:02 -0500 Message-ID: From: "Adrian Knox" Reply-To: "Adrian Knox" To: msec-archive@ietf.org Subject: The discreet replica store Date: Mon, 19 May 2008 16:22:02 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Prestige Replicas is now bigger and better than ever before! I'm sure you're familiar with this popular replica store, so I'm glad to announce that Prestige Replicas has been completely redesigned and now offers not only the highest quality replica watches but also handbags and jewelry! In addition, they're running a 15% special these days when you buy two watches! There's never been a better time to buy a replica watch, especially a Tag Heuer! With prices as low as $200, and the store unmatched privacy assurance guarantee, I'm sure you won't want to wait to get your superior quality Tag Heuer replica! http://kezytytubif44.blogspot.com/ From mext-bounces@ietf.org Tue May 20 01:34:50 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E5193A697B; Tue, 20 May 2008 01:34:50 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68D793A697B for ; Tue, 20 May 2008 01:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.811 X-Spam-Level: X-Spam-Status: No, score=-3.811 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lltR5GkCUcV for ; Tue, 20 May 2008 01:34:48 -0700 (PDT) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by core3.amsl.com (Postfix) with ESMTP id 515673A6977 for ; Tue, 20 May 2008 01:34:48 -0700 (PDT) Received: from ep_ms5_bk (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K1500KEYRTLFF@mailout1.samsung.com> for mext@ietf.org; Tue, 20 May 2008 17:34:33 +0900 (KST) Received: from ep_spt04 (ms5.samsung.com [203.254.225.113]) by ms5.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K1500MAKRTL8X@ms5.samsung.com> for mext@ietf.org; Tue, 20 May 2008 17:34:33 +0900 (KST) Content-return: prohibited Date: Tue, 20 May 2008 08:34:33 +0000 (GMT) From: Heejin Jang To: Jari Arkko Message-id: <32150809.109501211272473038.JavaMail.weblogic@epml03> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20080520083335676@heejin.jang X-MTR: 20080520083335676@heejin.jang X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML Cc: Alexandru Petrescu , "mext@ietf.org" Subject: Re: [MEXT] hiopt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: heejin.jang@samsung.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Jari. Thanks for your mail. Please see the inline. > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Tuesday, May 20, 2008 1:12 AM > To: heejin.jang@samsung.com > Cc: Vijay Devarapallli; mext@ietf.org; Alexandru Petrescu > Subject: hiopt > > Hi all, > > I have reviewed this thread and re-reviewed the draft. While > I sympathize with some of the questions Alex had, I see no > technical reason to block the draft from being approved, and > I see no support from the WG from doing this either. So I am > now approving the document. > > However, as a re-read the draft, I also noticed two additional issues. > The first issue is that Section 3 seems to be forgetting the > case where DHCP server has no information about a particular > home network. Due to this, I would like to make the following change: > > OLD: > In a network where the NAS is not co- > located with a DHCP relay nor a server, the server may not be > provided with the home network information from the NAS, and > thereby it may assign to a mobile node the home information > which has been preconfigured by the administrator or which is > acquired through a mechanism that is not described in this document. > NEW: > In a network where the NAS is not co- > located with a DHCP relay nor a server, the server may not be > provided with the home network information from the NAS, and > thereby it may either fail to provide information, or provide > home information which has been preconfigured by the > administrator or which is acquired through a mechanism that > is not described in this document. Ok. > Secondly, Section 4.2 and 4.3 talk about how relays can > provide information to servers. But I cannot see how the > server knows which piece of information from the relay > corresponds to what Home Information Option, in case there > were multiple options with different home network names. I am > a bit uncertain how to fix this, however. Perhaps it is > necessary to allow suboption type 1 in relay agent options, too. Actually this was considered when working on hiopt-03 where the relay is supposed to put an MN-NAI into the MIP6 relay option when relaying DHCP messages to the server. At that time I was also considered putting the (home) MSP too, but left it without further description because I'm not sure that we can mandate that the AAA server MUST deliver the home MSP's FQDN. 1) If yes, home MSP's FQDN can be delivered in suboption type 1 in the relay options as you suggested. (this will be finally compared with the target MSP requested by MN.). 2) If no, the server should return a (partially) matched HA FQDN, or a (partially) matched HN prefix/HA address after DNS resolution based on the target MSP requested by MN. It seems that 1) looks more explicit. Could you let me know your opinion? > Please suggest text, and I will place it in the RFC Editor > note part of the tracker and approve it. (Or you can submit a > new version with these > fixes.) > > Jari Thanks again. :) -Best regards, Heejin. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Tue May 20 02:07:07 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EF513A688E; Tue, 20 May 2008 02:07:07 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2988928C187 for ; Tue, 20 May 2008 02:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqRo7Z+1NgqQ for ; Tue, 20 May 2008 02:06:24 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 84C933A6BCA for ; Tue, 20 May 2008 02:06:19 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id E7A851986E3; Tue, 20 May 2008 12:06:19 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id A2AF6198665; Tue, 20 May 2008 12:06:19 +0300 (EEST) Message-ID: <4832948B.4090905@piuha.net> Date: Tue, 20 May 2008 12:06:19 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14ubu (X11/20080502) MIME-Version: 1.0 To: heejin.jang@samsung.com References: <32150809.109501211272473038.JavaMail.weblogic@epml03> In-Reply-To: <32150809.109501211272473038.JavaMail.weblogic@epml03> X-Virus-Scanned: ClamAV using ClamSMTP Cc: Alexandru Petrescu , "mext@ietf.org" Subject: Re: [MEXT] hiopt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > 1) If yes, home MSP's FQDN can be delivered in suboption type 1 in the relay options > as you suggested. (this will be finally compared with the target MSP requested by MN.). > > 2) If no, the server should return a (partially) matched HA FQDN, or a (partially) matched > HN prefix/HA address after DNS resolution based on the target MSP requested by MN. > > It seems that 1) looks more explicit. > Could you let me know your opinion? > I prefer option 1, but you need to change text earlier in the draft about where suboption 1 is legal. Make the changes, and submit a new version. Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From c.luebcke@westinvest.de Tue May 20 04:50:08 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 637583A6808; Tue, 20 May 2008 04:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.63 X-Spam-Level: X-Spam-Status: No, score=-21.63 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FS_REPLICA=0.994, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_DSBL=0.961, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJMTrcjkcQu2; Tue, 20 May 2008 04:50:06 -0700 (PDT) Received: from 73-228-90.dial.terra.cl (73-228-90.dial.terra.cl [200.90.228.73]) by core3.amsl.com (Postfix) with SMTP id 607F328C1CE; Tue, 20 May 2008 04:49:55 -0700 (PDT) X-Originating-IP: 10.247.195.168 by smtp.200.90.228.73; Tue, 20 May 2008 07:49:57 -0500 Message-ID: From: "Freda Mckinney" Reply-To: "Freda Mckinney" To: msec-archive@ietf.org Subject: Tag Heuer replicas better than originals Date: Tue, 20 May 2008 07:49:57 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit The new Porsche Design watches originated from the novel Titanium Chronograph from the 1970's, an absolutely unique creation due to the perfection of its workmanship. Based on its design, the Porsche Design Company developed an appealing, stylish, sporty and highly accurate watch. Unfortunately, these timepieces come with a high price tag. http://www.acoskke.com/ That's why a clever group of European manufacturers decided to offer the same exact functionality and style at greatly reduced prices: the Porsche Design replica watches. These replicas are so similar to the brand name pieces that it is practically impossible to tell them apart, other than by their price. They look the same, they function the same and they definitely don't have the same prices :) How would you like to browse through an amazing collection of these watches and marvel yourself with their low prices? Visit Prestige Replicas and see for yourself why sometimes replicas are so much better than the originals! http://www.acoskke.com/ From mext-bounces@ietf.org Tue May 20 05:11:09 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A75793A699F; Tue, 20 May 2008 05:11:09 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE9C73A699F for ; Tue, 20 May 2008 05:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsTHBRD0Jiqu for ; Tue, 20 May 2008 05:11:04 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 046E13A69D3 for ; Tue, 20 May 2008 05:11:03 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m4KCB1t14223; Tue, 20 May 2008 12:11:01 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 May 2008 07:10:03 -0500 Message-ID: In-Reply-To: <000601c8b7f1$77b54970$6510ef0a@psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-01.txt (Resend) Thread-Index: AciuWf2Y1JeerkUGQ46fWXJo4+sPHAJi0ddQAAHn2VAAAAgmQAAAcU1AAAA/eVAAAC0dUAAAOEgAAJ93hdA= References: <000601c8b7f1$77b54970$6510ef0a@psl.local> From: "Ahmad Muhanna" To: "Benjamin Lim" Cc: mext@ietf.org Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-01.txt (Resend) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ben, Thanks for the review, Appreciate it! please see comments inline. Regards, Ahmad > -----Original Message----- > From: Benjamin Lim [mailto:benjamin.limck@sg.panasonic.com] > Sent: Saturday, May 17, 2008 2:42 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: mext@ietf.org > Subject: RE: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-01.txt (Resend) > > Sorry due to some formatting error in my client. I resend my > previous mail. > > > -----Original Message----- > > Hi Ahmad, > > > > I snipped sections from the draft to reflect some comments (mostly > > editorial). > > > > Regards, > > Benjamin Lim > > > > ---------- > > > > 3.1. Binding Revocation Protocol > > > > ... > > On the other hand, the mobility access gateway usually sends a de- > > registration message by sending a Proxy BU with a lifetime > of zero to > > indicate to the local mobility anchor of the termination of the > > PMIPv6 mobile node binding registration. In this case, the > mobility > > access gateway include the MN home network prefix option > and the MN-ID > > option as per [2] in order for the local mobility anchor to > identify > > the mobile node > > PMIPv6 binding. However, in the case when the mobility > access gateway > > communicates a bulk termination of PMIPv6 sessions, the mobility > > access gateway sends a BRI message with the G bit set and > includes the > > mobility access gateway identity in the MN-ID option. When > the local > > mobility anchor receives such BRI message, it ensures that the > > mobility access gateway is authorized to send such bulk termination > > message and then process the BRI message accordingly. If the local > > mobility anchor processes the BRI message successfully and > the (A) bit > > is set in the BRI, the local mobility anchor responds to the mobile > > access gateway by sending a BRA message. > > Aditionally, the initiator of the binding revocation > > [Ben] s / Aditionally/ Additionally [Ahmad] Thx. > > > > procedure include an indication in the Revocation Trigger field to > > indicate to the receiving node the cause for the revocation > procedure. > > > > ... > > > > 3.3.1. Termination of Multiple Care-of Addresses Bindings > > > > In the case of multiple care-of addresses, the home agent maintains > > different binding for each pair of care-of address and home address. > > These bindings are also indexed and identified during the > mobile node > > registration using a new Binding ID mobility option [5]. In this > > case, the home agent may revoke any binding, more than one > binding, or > > all of the bindings for the same mobile node home address. > > > [Ben] Suggest reword above sentence to "In this case, the > home agent may revoke either one or multiple of the mobile > node's binding associated to the mobile node's home address." > > [Ahmad] Thanks. That is a better choice of words. > > ... > > > > Figure 2: Home Agent Revokes MN's Specific Registered Care-of > > Addresses Bindings > > > [Ben] What is 'Cause' specified in the BRA from MN to HA? [Ahmad] Thanks for spotting this! That actually should be status=success. > > > > ... > > > > 3.4.1. Local Mobility Anchor Revokes A PMIPv6 Binding > > > > The local mobility anchor may send a BRI message to the > mobile access > > gateway, hosting a specific proxy mobile IPv6 session, with the > > appropriate value in the revocation trigger field to > indicate that the > > mobile node binding has been terminated and the mobile > access gateway > > can clean up the applicable resources. When the mobile > access gateway > > receives a BRI message, the MAG identify the respected > > > [Ben] s /respected /respective [Ahmad] Ok. > > > > binding and if the A bit was set in the received BRI > message, the MAG > > sends a BRA message to the LMA. In this case, the MAG could send a > > Router Advertisement message to the MN with the home network prefix > > lifetime is set to zero. > > > > As an example, Figure 3, illustrates the message sequence > for revoking > > a mobile node binding at the source MAG during the MN inter- MAG > > handoff. > > During the inter-MAG handoff, the mobile node moves from the source > > MAG to the target MAG. The target MAG sends a PBU with the new > > care-of-address to the LMA to update the mobile node point of > > attachement. Since the MN binding at the LMA > > [Ben] s /attachement / attachment [Ahmad] Ok. > > > > points to the > > source MAG and upon receiving the PBU from the target MAG, > LMA updates > > the MN BCE and send a PBA to the target MAG. LMA can send a BRI > > message with the appropriate revocation trigger value, e.g. > > inter-MAG handoff indication, to the source MAG in order to > clean up > > the applicable resources reserved for the specified MN. The MAG > > acknowledges the BRI message by sending a BRA message to > indicate the > > success or failure of the termination of the mobile node binding. > > > > The process identified above can also be used by the LMA in > scenarios > > other than the inter-MAG handoff with the propoer > > [Ben] s / propoer / proper [Ahmad] I am not sure how that slipped the spell check. It seems that many did:) > > > > revocation trigger > > value to indicate to the peer MAG that a specific proxy mobile IPv6 > > binding or bindings have been revoked. > > > > Figure 3: LMA Revokes a MN Registration During Inter-MAG Handoff > > > [Ben] What is 'Cause' specified in the BRA from sMAG to LMA? [Ahmad] Thx. Similar to the above, status= success. > > > > ... > > > > 3.4.3. Mobile Access Gateway Revoke Bulk PMIPv6 Bindings > > > > The mobile access gateway send a de-registration PBU with > lifetime of > > zero as described in [2] to indicated to the LMA the > termination of a > > mobile node registration binding. > > However, the mobile access gateway sends a BRI message with > the G bit > > is set to indicate that all mobility sessions which are > registered at > > the LMA and attached to the MAG are being revoked as in > Section 9.2.1. > > When the LMA receives a BRI message with the G bit is set from a > > specified MAG, the LMA checks if the MAG is authorized to > use global > > revocations and responds with the approporiate status code > by sending > > [Ben] s/ approporiate / appropriate [Ahmad] Ok. Thx. > > > > a BRA message as in Section 8.2.2. > > > > ... > > > > 5.1. Binding Revocation Indication Message > > > > ... > > Binding ID mobility option [5]. This option is mandatory if the > > sending mobility entity request to terminate one binding of a multi > > care-of addresses bindings for the same mobile node. > > > [Ben] Suggest reword above sentence to "This option is > mandatory if the sending mobility entity request to terminate > a multiple care-of address registered binding of a mobile node." [Ahmad] Thx. Will adopt the proposed text. > > > > The sending Mobility entity may include more than one of these > > mobility options. > > > > ... > > > > 6.1. Sending Binding Revocation Messages > > > > When a mobility entity initiate the binding revocation process by > > sending a Binding Revocation Indication, the initiator MUST > construct > > the BRI message as described in Section 5.1. In the BRI > message, the > > initiator MUST set the Sequence Number field to the next sequence > > number available for Binding Revocation. Since sending Binding > > Revocation Indication messages is not done on a regular basis, a 16 > > bit sequence number field is large enough to allow the initiator to > > match the Binding Revocation Acknowledgement to the outstanding > > Binding Revocation Indication with (A) bit set using the seqeuence > > [Ben] s / seqeuence / sequence [Ahmad] Ok. > > > > number field only. > > > > ... > > > > 6.3. Retransmission of Binding Revocation Indication > > > > If the sending mobility entity does not receive a Binding > Revocation > > Acknowledgement in response to the outstanding Binding Revocation > > Indication before the MINDelayBRIs timer expires, the > mobility entity, > > e.g. LMA, may retransmit the same BRI message upto the > > [Ben] s/ upto / up to [Ahmad] Ok. > > > > BRIMaxRetriesNumber as defined in Section 11. If the revoking > > mobility entity does not receive a BRA message after the maximum > > number of retrasmits have been sent, the revoking > > [Ben] s/ retrasmits have been sent / retransmissions [Ahmad] Thanks! > > > > > mobility entity can > > clean the mobile node binding cache and all resources > associated with > > this binding. The revoking mobility entity may log the event. > > > > ... > > > > 7.2. Receiving Binding Revocation Acknowledgement > > > > ... > > > > If the Status field indicates any value other than success, > the home > > agent SHOULD examine any mobility options included in the Binding > > Revocation Acknowledgement. The home agent MAY log the approriate > > [Ben] s / approriate / appropriate [Ahmad] Ok. > > > > event to reflect the status of the received BRA. > > > > ... > > > > 8.1.1. Sending Binding Revocation Indication > > > > ... > > > > When the local mobility anchor needs to revoke all mobile > nodes proxy > > BCE that belong to a specific realm, e.g. > > @companyabc.com, and are registered with the local mobility > anchor and > > hosted at the mobile access gateway, > > > [Ben] Suggest reword the above to "When the local mobility > anchor needs to revoke all currently registered mobile nodes > proxy BCE that belong to a specific realm > (e.g.@companyabc.com) at a particular mobile access gateway," [Ahmad] Thanks again, will adopt the text. > > > > the local mobility anchor MUST set the Global (G) bit and > the value of > > the Revocation Trigger field to Local Policy. In this > case, the local > > mobility anchor MUST include a mobility option to identify the > > impacted bindings, e.g. MN-ID option with a wildcard NAI, e.g. > > *@companyabc.com, to identify all the mobile nodes BCEs > that need to > > be removed. > > > [Ben] Is there such a thing as a wildcard NAI? Why can't the > LMA just include every single affect MN-ID as an option in the BRI? [Ahmad] What I meant by wildcard NAI is something like "*@abcxyz.com". I believe allowing this is useful. If the LMA would like to revoke all mobile nodes by including multiple MN-IDs, I believe that is allowed, if the text is not clear, we will fix it. > > > > ... > > > > 8.2.1. Receiving Binding Revocation Indication > > > > ... > > > > The Revocation Trigger field value in the received Binding > Revocation > > Indication could be used by the local mobility anchor to > log an event > > or update some local parameters which tracks the satate of the peer > > [Ben] s / satate / state [Ahmad] Thanks. > > > > mobile access gateway. > > > > ... > > > > 9.1.2. Sending Binding Revocation Acknowledgement > > > > ... > > > > When the mobile access gateway receive a valid Binding Revocation > > [Ben] s / receive / receives [Ahmad] Ok. > > > > Indication with the (A) bit is set and after processing the BRI > > message, the mobile access gteway sends a packet to the local > > [Ben] s/ gteway / gateway [Ahmad] Ok. > > > > mobility anchor containing a Binding Revocation Acknowledgement > > according to the procedure in Section 6.1 and the following: > > > > ... > > > > 9.2.1. Sending Binding Revocation Indication > > > > ... > > > > The mobile access gateway send a Binding Revocation > Indication when it > > needs to use global revocation, i.e. when the G bit is set. > In this > > case when an event occurs which requires the mobile access > gateway to > > inform the local mobility anchor to terminate all mobile nodes > > bindings that are registered at the local mobility anchor and the > > mobile access gateway, the mobile access gateway send a Binding > > Revocation Inidcation message following Section 6.1 and the > > [Ben] s / Inidcation / Indication [Ahmad] Ok. > > > follwoing: > > [Ben] s / follwoing / following: [Ahmad] Ok. > > > > ... > > > > 9.2.2. Receiving Binding Revocation Acknowledgement > > > > ... > > > > If the Status field indicates (Global Revocation NOT > Authorized), the > > mobile access gateway is not authorized to participate in a > Per-Peer > > Global Revocation. The mobile access gateway SHOULD NOT > retry sending > > a Binding Revocation Inidication with the Global (G) > > [Ben] s / Inidication / Indication [Ahmad] Ok. > > > > bit is set to the same local mobility agent. The mobile access > > gateway should raise an alarm or log an event to indicate this > > rejection. > > > > ... > > > > 10.1. Receiving Binding Revocation Indication > > > > ... > > > > If the mobile node has registered multiple care-of > addresses with its > > home agent, the mobile node MUST verify which binding is > being revoked > > by examining the content of the BRI message. If the mobile node > > received a Binding Revocation Indication with a single or more than > > one BID options and its home adress is in the Home Address option, > > > [Ben] Suggest reword above to "If the mobile node receives a > Binding Revocation Indication containing either a single or > multiple BID options that is associated to its home address > specified in the Home Address option," [Ahmad] Thanks. > > > > the mobile node MUST consider its bindings identified in > the Binding > > ID options are being revoked. > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From taxrefund@0x0c.4xdb53d6.irs.gov Tue May 20 05:57:14 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4AAB3A6B87 for ; Tue, 20 May 2008 05:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.602 X-Spam-Level: X-Spam-Status: No, score=-90.602 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FORGED_MUA_OUTLOOK=3.116, MSOE_MID_WRONG_CASE=0.82, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_DSBL=0.961, SARE_HEXOCTDWORD=2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmZaL5Oe2Prw for ; Tue, 20 May 2008 05:57:11 -0700 (PDT) Received: from clutch.cc (clutch.cc [202.212.213.101]) by core3.amsl.com (Postfix) with ESMTP id C121E3A6B7F for ; Tue, 20 May 2008 05:57:10 -0700 (PDT) Received: from service (static-64-222-189-175.man.east.verizon.net [64.222.189.175]) by clutch.cc (Postfix) with ESMTP id EDBDF80CF5; Tue, 20 May 2008 21:57:01 +0900 (JST) Reply-To: taxrefund@0x0c.4xdb53d6.irs.gov From: Internal Revenue Service (IRS) Subject: Tax Notification Date: Tue, 20 May 2008 08:57:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20080520125701.EDBDF80CF5@clutch.cc> To: undisclosed-recipients:; Internal Revenue Service (IRS) United States Department of the Treasury Dear Taxpayer, After the last annual calculations of your fiscal activity we have determined that you are eligible to receive a tax refund of $184.80. Please submit the tax refund request and allow us 6-9 days in order to process it. A refund can be delayed for a variety of reasons. For example submitting invalid records or applying after the deadline. To access the form for your tax refund, use the following personalized link: http://0x7C.0xDB11D1/www.irs.gov/ Regards, Internal Revenue Service Document Reference: (0x7C.0xDB11D1). From mext-bounces@ietf.org Wed May 21 14:37:06 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E30773A68FD; Wed, 21 May 2008 14:37:05 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 913A03A6905 for ; Wed, 21 May 2008 14:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiR34oMwBJ0c for ; Wed, 21 May 2008 14:37:03 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 2B4463A68CD for ; Wed, 21 May 2008 14:37:03 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m4LLb1KJ011739; Wed, 21 May 2008 16:37:01 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 May 2008 16:37:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 May 2008 17:36:58 -0400 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA058DE247@ecamlmw720.eamcs.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-00.txt thread-index: AcisZgajIsShiz9NSrC1XTquiR0ADwAM8ZNgAsK5Iu0A+XQdIA== References: From: "Suresh Krishnan" To: "Basavaraj Patil" , "ext Ahmad Muhanna" , "Brian Haley" , "Behcet Sarikaya" X-OriginalArrivalTime: 21 May 2008 21:37:00.0908 (UTC) FILETIME=[CD95B2C0:01C8BB8A] Cc: mext@ietf.org Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Folks, I think it is better to use different MH types for the revocation and generic notification messages a) The semantics of the messages are different b) The security requirements for the messages are different Cheers Suresh > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of Basavaraj Patil > Sent: May-16-08 6:32 PM > To: ext Ahmad Muhanna; Brian Haley; Behcet Sarikaya > Cc: mext@ietf.org > Subject: Re: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-00.txt > > > FWIW, I think Ahmad does have a point about whether to define > a new MH type message for revocation or to reuse the > gen-notification message. > It is possible to consider revocation as merely a > notification to the MN or the MAG in the case of PMIP6 in > which case the gen-notification approach is sufficient. > However I think that the revocation of the binding is more > than mere notification. IMO, gen-notification is for purposes > such as informing the MN about other non-critical things. > Revocation is tied to the mobility of the MN and hence would > be used to trigger possibly other actions (such as recharging > a prepaid account or connecting the MN to a provisioning site etc.). > So it makes sense to define revocation messages via new MH type. > > While we can utilize the gen-notification messages to solve > the revocation problem as I do not see a major technical > issue with it, it may not be the most elegant one and this > difference of views is more semantic than syntactic. > > -Raj > > > On 5/2/08 4:24 PM, "ext Ahmad Muhanna" wrote: > > > Hi Brian, > > Please see comment inline. > > > > Regards, > > Ahmad > > > > > >> Action:draft-muhanna-mext-binding-revocation-00.txt > >> > >> Hi Behcet, > >> > >> Behcet Sarikaya wrote: > >>> Hi Brian, > >>> I agree that generic notifications can support binding > >> revocation. > >>> My concern is that there is no use case clearly defined in > >> the generic > >>> notifications draft. As such it is too "generic". On the > other hand > >>> binding revocation is more clearly defined, in fact it is > >> (should be) > >>> part of BU/BA exchange semantics. > >> > >> I'll let WG consensus decide if revocation should define > two new MH > >> types or use gen-notification. > >> > >>> For example, can you say that generic notifications can > >> be used for > >>> handover? > >> > >> Well, if I wrote the Generic Notification draft first, HA Switch > >> could have maybe just been a mobility option. > > > > [Ahmad] > > It actually depends on the scope, for example, if we go a > little back > > in time and according to the "request/Reply" scope for the Generic > > Notification Message that was mentioned earlier: may be; we > could have > > defined MIP6 BU/BA as Generic Notification Messages and > closed all the > > books and saved ourselves a lot of time and resources. > > > > Cheers! > > > >> > >> -Brian > >> > >>> ----- Original Message ---- > >>> From: Brian Haley > >>> To: Vijay Devarapallli > >>> Cc: mext > >>> Sent: Wednesday, April 30, 2008 1:48:02 PM > >>> Subject: Re: [MEXT] FW: I-D > >>> Action:draft-muhanna-mext-binding-revocation-00.txt > >>> > >>> Hi Vijay, > >>> > >>> I've been talking with Ahmad and Sri about this off-line > and we're > >>> trying to come to an agreement over some of the text in > >>> gen-notification to more easily support the revocation draft. > >>> Hopefully an update will be agreeable to everyone, but I wouldn't > >>> necessarily hold-up the current revocation draft for it. > >> That's my thoughts at least. > >>> > >>> -Brian > >>> > >>> Vijay Devarapallli wrote: > >>>> Hi Ahmad and others, > >>>> > >>>> We previously had a discussion on this draft on the MIP6 mailing > >>> list > and it was agreed that the binding revocation > >> message will be > >>> a > sub-type in the Generic Notification Message. > >>>> > >>> > >> > http://www.ietf.org/internet-drafts/draft-haley-mext-generic-notifica > >> t > >>> ion-message-00.txt > >>>> > >>>> We would need to modify the generic notification message > >> to include > >>> a > new 'subtype' field. We had discussed this in the past > >> and made > >>> no > progress. We can start with the following values > > 0 - > >>> Reserved, not used > 1 - Notification message indicated by > >> Mobility > >>> Options > 2 - Binding Revocation Indication > 3 - Binding > >> Revocation > >>> Acknowledgement > 4-255 reserved > > The Generic Notification > >>> message draft is quite simple and shouldn't > take too long to > >>> standardize. It would be a good idea to use the > Generic > >>> Notification message as much as > possible when you have > >> something to > >>> notify to either the mobile node > or the home agent. > Otherwise we > >>> might end up with a proliferation of > notification > >> messages using up > >>> a lot of mobility header message types. > >>>> > >>>> Vijay > >>>> > >>>> On Tue, Apr 29, 2008 at 6:32 PM, Ahmad Muhanna > >> >>> > wrote: > >>>>> Hello All, > >>>>> > >>>>> Please find the latest Binding Revocation for IPv6 > >> Mobility draft > >>> at the >> below link. > >>>>> We highly value your review and comments! > >>>>> > >>>>> Many Thanks in advance! > >>>>> > >>>>> Best Regards, > >>>>> Ahmad > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: i-d-announce-bounces@ietf.org > >>> > >>>>> [mailto:i-d-announce-bounces@ietf.org > >>> ] On Behalf Of >> > >>> Internet-Drafts@ietf.org > >>>> Sent: > >>> Tuesday, April 29, 2008 8:30 PM >> To: i-d-announce@ietf.org > >>> >> Subject: I-D > >>> Action:draft-muhanna-mext-binding-revocation-00.txt > >>>>> > >>>>> A New Internet-Draft is available from the on-line > >>> Internet-Drafts >> directories. > >>>>> > >>>>> Title : Binding Revocation for IPv6 Mobility > >>>>> Author(s) : A. Muhanna, et al. > >>>>> Filename : > >> draft-muhanna-mext-binding-revocation-00.txt > >>>>> Pages : 32 > >>>>> Date : 2008-04-29 > >>>>> > >>>>> This document defines the revocation semantics for > >> terminating a > >>> mobile >> node's mobility session and associated > >> resources. These > >>> semantics are >> generic enough and can be used by > >> mobility entities > >>> in the case of >> Client Mobile IPv6 and its extensions. This > >>> mechanism allows the >> mobility entity which initiates the > >>> revocation procedure to request its >> corresponding one to > >>> terminate either one, multiple or all specified >> > >> binding cache entries. > >>>>> > >>>>> A URL for this Internet-Draft is: > >>>>> > >>> > >> > http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revoca > >> t > >>> io > >>>>> n-00.txt > >>>>> > >>>>> Internet-Drafts are also available by anonymous FTP at: > >>>>> ftp://ftp.ietf.org/internet-drafts/ > >>>>> > >>>>> Below is the data which will enable a MIME compliant > >> mail reader > >>>>> implementation to automatically retrieve the ASCII > >> version of the > >>>>> Internet-Draft. > >>>>> > >>>>> _______________________________________________ > >>>>> MEXT mailing list > >>>>> MEXT@ietf.org >> > >>> https://www.ietf.org/mailman/listinfo/mext > >>>>> > >>>>> > >>>> > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mext > >>> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > >> > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed May 21 19:25:12 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8A193A6A7D; Wed, 21 May 2008 19:25:12 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C0A23A688B for ; Wed, 21 May 2008 19:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9b6ETAqRxUc for ; Wed, 21 May 2008 19:25:10 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 90C783A6A7D for ; Wed, 21 May 2008 19:25:10 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id m4M2PFQT010557; Thu, 22 May 2008 11:25:15 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb2) with ESMTP id m4M2PED24430; Thu, 22 May 2008 11:25:14 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili04) with ESMTP id m4M2PEK17634; Thu, 22 May 2008 11:25:14 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.116]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 May 2008 10:24:18 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Thu, 22 May 2008 10:24:15 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Thu, 22 May 2008 10:24:15 +0800 From: "Benjamin Lim" To: "'Ahmad Muhanna'" References: <000601c8b7f1$77b54970$6510ef0a@psl.local> Date: Thu, 22 May 2008 10:24:15 +0800 Message-ID: <007a01c8bbb2$ee3bfa20$7471510a@psl.local> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: thread-index: AciuWf2Y1JeerkUGQ46fWXJo4+sPHAJi0ddQAAHn2VAAAAgmQAAAcU1AAAA/eVAAAC0dUAAAOEgAAJ93hdAAT+2v8A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 22 May 2008 02:24:18.0395 (UTC) FILETIME=[EFED7AB0:01C8BBB2] Cc: mext@ietf.org Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-01.txt (Resend) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad, Reply to one of your comment. I snip out the part. =8==8<=8== > > [Ben] Is there such a thing as a wildcard NAI? Why can't > the LMA just > > include every single affect MN-ID as an option in the BRI? > [Ahmad] > > What I meant by wildcard NAI is something like > "*@abcxyz.com". I believe allowing this is useful. If the LMA > would like to revoke all mobile nodes by including multiple > MN-IDs, I believe that is allowed, if the text is not clear, > we will fix it. [Ben] Ok I get your idea. Meaning a NAI that represent a group of MNs belong to a particular domain. I suggest the following wording then. ... 8.1.1. Sending Binding Revocation Indication ... In this case, the local mobility anchor MUST include a mobility option to identify the impacted bindings, e.g. MN-ID option with a wildcard NAI, e.g. *@companyabc.com, to identify all the mobile nodes BCEs that need to be removed. In this case, the local mobility anchor MUST include a mobility option to identify the impacted bindings. For example, if the local mobility anchor wants to revoke the bindings of all mobile nodes from a particular domain (companyabc.com), the local mobility anchor would include multiple MN-ID options to reflect the NAI of the affect mobile nodes. Another way for the local mobility anchor to revoke all bindings from companyabc.com would be to use a special NAI that represent mobile nodes from this domain. For this, the local mobility anchor would only include a single MN-ID option containing this special NAI to identify all the mobile nodes BCEs that need to be removed. How does this sound? Regards, Benjamin Lim _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 22 05:59:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35E553A6B0A; Thu, 22 May 2008 05:59:51 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EE833A6B0A for ; Thu, 22 May 2008 05:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.134 X-Spam-Level: X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8LtxERh1Nao for ; Thu, 22 May 2008 05:59:45 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 984FF28C16A for ; Thu, 22 May 2008 05:59:45 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m4MCxmm28672; Thu, 22 May 2008 12:59:48 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 22 May 2008 07:59:43 -0500 Message-ID: In-Reply-To: <007a01c8bbb2$ee3bfa20$7471510a@psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-01.txt (Resend) Thread-Index: AciuWf2Y1JeerkUGQ46fWXJo4+sPHAJi0ddQAAHn2VAAAAgmQAAAcU1AAAA/eVAAAC0dUAAAOEgAAJ93hdAAT+2v8AAXAjuw References: <000601c8b7f1$77b54970$6510ef0a@psl.local> <007a01c8bbb2$ee3bfa20$7471510a@psl.local> From: "Ahmad Muhanna" To: "Benjamin Lim" Cc: mext@ietf.org Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-01.txt (Resend) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ben, The text looks good. In the next revision, "hopefully as a wg document" I will make sure that the intent of the text is captured. Again, Many thanks for your review. Regards, Ahmad > -----Original Message----- > From: Benjamin Lim [mailto:benjamin.limck@sg.panasonic.com] > Sent: Wednesday, May 21, 2008 9:24 PM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: mext@ietf.org > Subject: RE: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-01.txt (Resend) > > Hi Ahmad, > > Reply to one of your comment. I snip out the part. > > =8==8<=8== > > > [Ben] Is there such a thing as a wildcard NAI? Why can't > > the LMA just > > > include every single affect MN-ID as an option in the BRI? > > [Ahmad] > > > > What I meant by wildcard NAI is something like "*@abcxyz.com". I > > believe allowing this is useful. If the LMA would like to > revoke all > > mobile nodes by including multiple MN-IDs, I believe that > is allowed, > > if the text is not clear, we will fix it. > [Ben] Ok I get your idea. Meaning a NAI that represent a > group of MNs belong to a particular domain. I suggest the > following wording then. > > ... > > 8.1.1. Sending Binding Revocation Indication > > ... > > > In this case, the local mobility anchor MUST include a > mobility option to identify the impacted bindings, e.g. > MN-ID option with a wildcard NAI, e.g. > *@companyabc.com, to identify all the mobile nodes BCEs that > need to be removed. > > > > In this case, the local mobility anchor MUST include a > mobility option to identify the impacted bindings. For > example, if the local mobility anchor wants to revoke the > bindings of all mobile nodes from a particular domain > (companyabc.com), the local mobility anchor would include > multiple MN-ID options to reflect the NAI of the affect > mobile nodes. Another way for the local mobility anchor to > revoke all bindings from companyabc.com would be to use a > special NAI that represent mobile nodes from this domain. For > this, the local mobility anchor would only include a single > MN-ID option containing this special NAI to identify all the > mobile nodes BCEs that need to be removed. > > How does this sound? > > Regards, > Benjamin Lim > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 22 07:33:02 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A41028C17A; Thu, 22 May 2008 07:33:02 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6614C28C17A for ; Thu, 22 May 2008 07:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.811 X-Spam-Level: X-Spam-Status: No, score=-3.811 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 764aoGRd2oOh for ; Thu, 22 May 2008 07:32:55 -0700 (PDT) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by core3.amsl.com (Postfix) with ESMTP id 40C903A6AB1 for ; Thu, 22 May 2008 07:32:54 -0700 (PDT) Received: from ep_ms5_bk (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K19009DYXQUX6@mailout3.samsung.com> for mext@ietf.org; Thu, 22 May 2008 23:32:54 +0900 (KST) Received: from ep_spt01 (ms5.samsung.com [203.254.225.113]) by ms5.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K19004KPXQU4S@ms5.samsung.com> for mext@ietf.org; Thu, 22 May 2008 23:32:54 +0900 (KST) Content-return: prohibited Date: Thu, 22 May 2008 14:32:54 +0000 (GMT) From: Heejin Jang To: Jari Arkko Message-id: <17085136.236881211466774482.JavaMail.weblogic@epml08> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20080522142456287@heejin.jang X-MTR: 20080522142456287@heejin.jang X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML Cc: Alexandru Petrescu , "mext@ietf.org" Subject: Re: [MEXT] hiopt (Revised text) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: heejin.jang@samsung.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Jari and Vijay. I revised the draft as Jari's two comments. Kindly see the below and give me your feedbacks. Thanks for your kind cooperation. :) * Modified points 1) The 3rd paragragh was modifed according to the Jari's 1st comment. 2) For the 2nd comments, we allowed the Sub-opt-code 1 and mandated it in a MIP6 Relay option. 1> In Section 3.3 (Common Sub-options), page 9, Old: While the Sub-opt-code 1 is only available in both the requesting and the returned Home Network Information options, Sub-opt-codes 2, 3, 4, and 5 are available only in the returned Home Network Information option and the MIP6 Relay Agent option. New: While the Sub-opt-codes 1, 2, 3, 4, and 5 are available in the MIP6 Relay Agent option and the Home Network Information option returned by the DHCP server, a value of 1 is the only Sub-opt-code available in the requesting Home Network Information option by the mobile node. 2> In Section 4.2 (NAS/DHCP Relay Agent Behavior), page 13, 2nd paragraph, Old: The relay SHOULD include each home network parameter in a sub-option, and include all sub-options in a single MIP6 Relay Agent option. It MUST NOT include any sub-option whose Sub-opt-code is other than 2, 3, 4, and 5 as described in Section 3.3. New: (added paragraph) When providing the home network information, the relay MUST include a sub-option whose Sub-opt-code is 1, and set the Home Network Parameter field to the FQDN of the network where the home information is assigned. That FQDN information will be compared with the target MSP requested by the mobile node when a DHCP server searches for the matching information. The relay SHOULD include each home network parameter in a sub-option, and include all sub-options in a single MIP6 Relay Agent option. It MUST NOT include any sub-option whose Sub-opt-code is other than 1, 2, 3, 4, and 5 as described in Section 3.3. 3> In Section 4.3 (DHCP Server Behavior), page 13, Old: The home network information received from the relay SHOULD be kept in the server so that the server can provide the information when it is requested by the mobile node. The server MUST ignore any sub-option in a MIP6 Relay Agent option whose Sub-opt-code is other than 2, 3, 4, and 5, as described in Section 3.3. New: The MIP6 Relay Agent option which does not include a sub-option with Sub-opt-code 1 MUST be ignored. Otherwise, the home network information received from the relay SHOULD be kept in the server so that the server can provide the information when it is requested by the mobile node. The server MUST ignore any sub-option in a MIP6 Relay Agent option whose Sub-opt-code is other than 1, 2, 3, 4, and 5, as described in Section 3.3. 4> In page 14, case B, Old: Any Home Network Information option which carries more than one target MSP or which does not carry any target MSP MUST be ignored. New: Any Home Network Information option which carries more than one target MSP or which does not carry any target MSP MUST be ignored. Otherwise, the DHCP server searches its database by using the received target MSP as a key. 5> In page 15, the 8nd paragraph Old: The DHCP server should provide all of the matching home information in Home Network Information option(s) based on its policy. It may return partially matched results. For example, on receipt of a Home Network Information option which specifies "xxx.example.com" as the target network, it may return "example.com" to the mobile node. In this case, "xxx.example.com" is returned in a sub-option with Sub- opt-code 1, and "example.com" in a sub-option with Sub-opt-code 5. Note that the detailed rule for returning partially matched instances of home network information follows the server's own policy and is outside the scope of this document. New: The DHCP server should provide all of the matching home information in Home Network Information option(s) based on its policy. While searching for the home network information by using the target MSP as a key, it may return the results when the key is partially matched. For example, on receipt of a Home Network Information option which specifies "xxx.example.com" as the target network, it may return the home network information assigned for "example.com" to the mobile node. Note that the detailed rule for returning partially matched instances of home network information follows the server's own policy and is outside the scope of this document. 6> In Section 6 (IANA) Old: o Home network identifier 1 (only allowed in the Home Network Information option; value Reserved for the MIP6 Relay Agent option) New: o Home network identifier 1 Thanks for your kind help. - All the best heejin. ------- Original Message ------- Sender : Jari Arkko Date : 2008-05-20 01:12 (GMT+09:00) Title : hiopt Hi all, I have reviewed this thread and re-reviewed the draft. While I sympathize with some of the questions Alex had, I see no technical reason to block the draft from being approved, and I see no support from the WG from doing this either. So I am now approving the document. However, as a re-read the draft, I also noticed two additional issues. The first issue is that Section 3 seems to be forgetting the case where DHCP server has no information about a particular home network. Due to this, I would like to make the following change: OLD: In a network where the NAS is not co- located with a DHCP relay nor a server, the server may not be provided with the home network information from the NAS, and thereby it may assign to a mobile node the home information which has been preconfigured by the administrator or which is acquired through a mechanism that is not described in this document. NEW: In a network where the NAS is not co- located with a DHCP relay nor a server, the server may not be provided with the home network information from the NAS, and thereby it may either fail to provide information, or provide home information which has been preconfigured by the administrator or which is acquired through a mechanism that is not described in this document. Secondly, Section 4.2 and 4.3 talk about how relays can provide information to servers. But I cannot see how the server knows which piece of information from the relay corresponds to what Home Information Option, in case there were multiple options with different home network names. I am a bit uncertain how to fix this, however. Perhaps it is necessary to allow suboption type 1 in relay agent options, too. Please suggest text, and I will place it in the RFC Editor note part of the tracker and approve it. (Or you can submit a new version with these fixes.) Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 22 08:03:53 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D773128C2A1; Thu, 22 May 2008 08:03:52 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CA9928C279 for ; Thu, 22 May 2008 08:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywSHRAeglbFQ for ; Thu, 22 May 2008 08:03:49 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 43BAF28C2A1 for ; Thu, 22 May 2008 08:03:49 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K1900AB2Z6JTL@usaga04-in.huawei.com> for mext@ietf.org; Thu, 22 May 2008 10:03:56 -0500 (CDT) Received: from xiayangsong ([10.124.12.53]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K1900CWQZ6HLW@usaga04-in.huawei.com> for mext@ietf.org; Thu, 22 May 2008 10:03:55 -0500 (CDT) Date: Thu, 22 May 2008 10:03:53 -0500 From: Frank Xia To: heejin.jang@samsung.com Message-id: <000901c8bc1d$0d8088a0$350c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <17085136.236881211466774482.JavaMail.weblogic@epml08> Cc: mext@ietf.org Subject: Re: [MEXT] hiopt (Revised text) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1822401329==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1822401329== Content-type: multipart/alternative; boundary="Boundary_(ID_3ippMJ+Ra7tTUp2224FbDw)" This is a multi-part message in MIME format. --Boundary_(ID_3ippMJ+Ra7tTUp2224FbDw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Heejin In this draft, a MN uses DHCPv6 to acquire home network information. However, if MN only has IPv4 CoA in DSMIPv6 scenario, IMO, DHCPv4 support is needed. What is your opinion? BR Frank ----- Original Message ----- From: Heejin Jang To: Jari Arkko Cc: Alexandru Petrescu ; mext@ietf.org Sent: Thursday, May 22, 2008 9:32 AM Subject: Re: [MEXT] hiopt (Revised text) Hi, Jari and Vijay. I revised the draft as Jari's two comments. Kindly see the below and give me your feedbacks. Thanks for your kind cooperation. :) * Modified points 1) The 3rd paragragh was modifed according to the Jari's 1st comment. 2) For the 2nd comments, we allowed the Sub-opt-code 1 and mandated it in a MIP6 Relay option. 1> In Section 3.3 (Common Sub-options), page 9, Old: While the Sub-opt-code 1 is only available in both the requesting and the returned Home Network Information options, Sub-opt-codes 2, 3, 4, and 5 are available only in the returned Home Network Information option and the MIP6 Relay Agent option. New: While the Sub-opt-codes 1, 2, 3, 4, and 5 are available in the MIP6 Relay Agent option and the Home Network Information option returned by the DHCP server, a value of 1 is the only Sub-opt-code available in the requesting Home Network Information option by the mobile node. 2> In Section 4.2 (NAS/DHCP Relay Agent Behavior), page 13, 2nd paragraph, Old: The relay SHOULD include each home network parameter in a sub-option, and include all sub-options in a single MIP6 Relay Agent option. It MUST NOT include any sub-option whose Sub-opt-code is other than 2, 3, 4, and 5 as described in Section 3.3. New: (added paragraph) When providing the home network information, the relay MUST include a sub-option whose Sub-opt-code is 1, and set the Home Network Parameter field to the FQDN of the network where the home information is assigned. That FQDN information will be compared with the target MSP requested by the mobile node when a DHCP server searches for the matching information. The relay SHOULD include each home network parameter in a sub-option, and include all sub-options in a single MIP6 Relay Agent option. It MUST NOT include any sub-option whose Sub-opt-code is other than 1, 2, 3, 4, and 5 as described in Section 3.3. 3> In Section 4.3 (DHCP Server Behavior), page 13, Old: The home network information received from the relay SHOULD be kept in the server so that the server can provide the information when it is requested by the mobile node. The server MUST ignore any sub-option in a MIP6 Relay Agent option whose Sub-opt-code is other than 2, 3, 4, and 5, as described in Section 3.3. New: The MIP6 Relay Agent option which does not include a sub-option with Sub-opt-code 1 MUST be ignored. Otherwise, the home network information received from the relay SHOULD be kept in the server so that the server can provide the information when it is requested by the mobile node. The server MUST ignore any sub-option in a MIP6 Relay Agent option whose Sub-opt-code is other than 1, 2, 3, 4, and 5, as described in Section 3.3. 4> In page 14, case B, Old: Any Home Network Information option which carries more than one target MSP or which does not carry any target MSP MUST be ignored. New: Any Home Network Information option which carries more than one target MSP or which does not carry any target MSP MUST be ignored. Otherwise, the DHCP server searches its database by using the received target MSP as a key. 5> In page 15, the 8nd paragraph Old: The DHCP server should provide all of the matching home information in Home Network Information option(s) based on its policy. It may return partially matched results. For example, on receipt of a Home Network Information option which specifies "xxx.example.com" as the target network, it may return "example.com" to the mobile node. In this case, "xxx.example.com" is returned in a sub-option with Sub- opt-code 1, and "example.com" in a sub-option with Sub-opt-code 5. Note that the detailed rule for returning partially matched instances of home network information follows the server's own policy and is outside the scope of this document. New: The DHCP server should provide all of the matching home information in Home Network Information option(s) based on its policy. While searching for the home network information by using the target MSP as a key, it may return the results when the key is partially matched. For example, on receipt of a Home Network Information option which specifies "xxx.example.com" as the target network, it may return the home network information assigned for "example.com" to the mobile node. Note that the detailed rule for returning partially matched instances of home network information follows the server's own policy and is outside the scope of this document. 6> In Section 6 (IANA) Old: o Home network identifier 1 (only allowed in the Home Network Information option; value Reserved for the MIP6 Relay Agent option) New: o Home network identifier 1 Thanks for your kind help. - All the best heejin. ------- Original Message ------- Sender : Jari Arkko Date : 2008-05-20 01:12 (GMT+09:00) Title : hiopt Hi all, I have reviewed this thread and re-reviewed the draft. While I sympathize with some of the questions Alex had, I see no technical reason to block the draft from being approved, and I see no support from the WG from doing this either. So I am now approving the document. However, as a re-read the draft, I also noticed two additional issues. The first issue is that Section 3 seems to be forgetting the case where DHCP server has no information about a particular home network. Due to this, I would like to make the following change: OLD: In a network where the NAS is not co- located with a DHCP relay nor a server, the server may not be provided with the home network information from the NAS, and thereby it may assign to a mobile node the home information which has been preconfigured by the administrator or which is acquired through a mechanism that is not described in this document. NEW: In a network where the NAS is not co- located with a DHCP relay nor a server, the server may not be provided with the home network information from the NAS, and thereby it may either fail to provide information, or provide home information which has been preconfigured by the administrator or which is acquired through a mechanism that is not described in this document. Secondly, Section 4.2 and 4.3 talk about how relays can provide information to servers. But I cannot see how the server knows which piece of information from the relay corresponds to what Home Information Option, in case there were multiple options with different home network names. I am a bit uncertain how to fix this, however. Perhaps it is necessary to allow suboption type 1 in relay agent options, too. Please suggest text, and I will place it in the RFC Editor note part of the tracker and approve it. (Or you can submit a new version with these fixes.) Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --Boundary_(ID_3ippMJ+Ra7tTUp2224FbDw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi Heejin
 
In this draft, a MN uses DHCPv6 to acquire home network information.
 
However, if MN only has IPv4 CoA in DSMIPv6 scenario, IMO,
DHCPv4 support is needed.
 
What is your opinion?
 
BR
Frank
----- Original Message -----
Sent: Thursday, May 22, 2008 9:32 AM
Subject: Re: [MEXT] hiopt (Revised text)

Hi, Jari and Vijay.

I revised the draft as Jari's two comments.
Kindly see the below and give me your feedbacks.

Thanks for your kind cooperation. :)

* Modified points

1) The 3rd paragragh was modifed according to the Jari's 1st comment.
2) For the 2nd comments, we allowed the Sub-opt-code 1 and mandated it in
a MIP6 Relay option.


1>  In Section 3.3 (Common Sub-options), page 9,

Old:  

   While the Sub-opt-code 1 is only available in both the requesting and
   the returned Home Network Information options, Sub-opt-codes 2, 3, 4,
   and 5 are available only in the returned Home Network Information
   option and the MIP6 Relay Agent option.

New:

   While the Sub-opt-codes 1, 2, 3, 4, and 5 are available in the MIP6
   Relay Agent option and the Home Network Information option returned
   by the DHCP server, a value of 1 is the only Sub-opt-code available
   in the requesting Home Network Information option by the mobile node.

2> In Section 4.2 (NAS/DHCP Relay Agent Behavior), page 13, 2nd paragraph,

Old:

  The relay SHOULD include each home network
   parameter in a sub-option, and include all sub-options in a single
   MIP6 Relay Agent option.  It MUST NOT include any sub-option whose
   Sub-opt-code is other than 2, 3, 4, and 5 as described in Section
   3.3.

New:

 (added paragraph)
  When providing the home network information, the
   relay MUST include a sub-option whose Sub-opt-code is 1, and set the
   Home Network Parameter field to the FQDN of the network where the
   home information is assigned.  That FQDN information will be compared
   with the target MSP requested by the mobile node when a DHCP server
   searches for the matching information.

   The relay SHOULD include each home network parameter in a sub-option,
   and include all sub-options in a single MIP6 Relay Agent option.  It
   MUST NOT include any sub-option whose Sub-opt-code is other than 1,
   2, 3, 4, and 5 as described in Section 3.3.
 
3>  In Section 4.3 (DHCP Server Behavior), page 13,

Old:

   The home network information
   received from the relay SHOULD be kept in the server so that the
   server can provide the information when it is requested by the mobile
   node. 

  The server MUST ignore any sub-option in a MIP6 Relay Agent option
   whose Sub-opt-code is other than 2, 3, 4, and 5, as described in
   Section 3.3.

New:

  The MIP6 Relay Agent option which
   does not include a sub-option with Sub-opt-code 1 MUST be ignored.
   Otherwise, the home network information received from the relay
   SHOULD be kept in the server so that the server can provide the
   information when it is requested by the mobile node. 

  The server MUST ignore any sub-option in a MIP6 Relay Agent option
  whose Sub-opt-code is other than 1, 2, 3, 4, and 5, as described in
  Section 3.3.

4> In page 14, case B,

Old:
         Any Home Network Information option which carries more than
         one target MSP or which does not carry any target MSP MUST be
         ignored.

New:

        Any Home Network Information option which carries more than
        one target MSP or which does not carry any target MSP MUST be
        ignored. Otherwise, the DHCP server searches its database
        by using the received target MSP as a key.

5> In page 15, the 8nd paragraph

Old:

   The DHCP server should provide all of the matching home information
   in Home Network Information option(s) based on its policy.  It may
   return partially matched results.  For example, on receipt of a Home
   Network Information option which specifies "xxx.example.com" as the
   target network, it may return "example.com" to the mobile node.  In
   this case, "xxx.example.com" is returned in a sub-option with Sub-
   opt-code 1, and "example.com" in a sub-option with Sub-opt-code 5.
   Note that the detailed rule for returning partially matched instances
   of home network information follows the server's own policy and is
   outside the scope of this document.

New:

   The DHCP server should provide all of the matching home information
   in Home Network Information option(s) based on its policy.  While
   searching for the home network information by using the target MSP as
   a key, it may return the results when the key is partially matched.
   For example, on receipt of a Home Network Information option which
   specifies "xxx.example.com" as the target network, it may return the
   home network information assigned for "example.com" to the mobile
   node.  Note that the detailed rule for returning partially matched
   instances of home network information follows the server's own policy
   and is outside the scope of this document.

6> In Section 6 (IANA)

Old:
       o Home network identifier                  1
         (only allowed in the Home Network
         Information option; value Reserved
         for the MIP6 Relay Agent option)

New:
       o Home network identifier                  1


Thanks for your kind help.

- All the best
heejin.


------- Original Message -------
Sender : Jari Arkko<jari.arkko@piuha.net>
Date   : 2008-05-20 01:12 (GMT+09:00)
Title  : hiopt

Hi all,

I have reviewed this thread and re-reviewed the draft. While I
sympathize with some of the questions Alex had, I see no technical
reason to block the draft from being approved, and I see no support from
the WG from doing this either. So I am now approving the document.

However, as a re-read the draft, I also noticed two additional issues.
The first issue is that Section 3 seems to be forgetting the case where
DHCP server has no information about a particular home network. Due to
this, I would like to make the following change:

OLD:
In a network where the NAS is not co-
located with a DHCP relay nor a server, the server may not be
provided with the home network information from the NAS, and thereby
it may assign to a mobile node the home information which has been
preconfigured by the administrator or which is acquired through a
mechanism that is not described in this document.
NEW:
In a network where the NAS is not co-
located with a DHCP relay nor a server, the server may not be
provided with the home network information from the NAS, and thereby
it may either fail to provide information, or provide home information
which has been preconfigured by the administrator or which is acquired
through a mechanism that is not described in this document.

Secondly, Section 4.2 and 4.3 talk about how relays can provide
information to servers. But I cannot see how the server knows which
piece of information from the relay corresponds to what Home Information
Option, in case there were multiple options with different home network
names. I am a bit uncertain how to fix this, however. Perhaps it is
necessary to allow suboption type 1 in relay agent options, too.

Please suggest text, and I will place it in the RFC Editor note part of
the tracker and approve it. (Or you can submit a new version with these
fixes.)

Jari
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext
--Boundary_(ID_3ippMJ+Ra7tTUp2224FbDw)-- --===============1822401329== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1822401329==-- From mext-bounces@ietf.org Thu May 22 10:01:22 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00B673A6AA6; Thu, 22 May 2008 10:01:21 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CBFB3A6941 for ; Thu, 22 May 2008 10:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcJl0Em1r392 for ; Thu, 22 May 2008 10:01:00 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id EE08B3A68D6 for ; Thu, 22 May 2008 10:00:56 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 85D8B198782; Thu, 22 May 2008 20:00:56 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 1710D1986D7; Thu, 22 May 2008 20:00:56 +0300 (EEST) Message-ID: <4835A6C7.5080400@piuha.net> Date: Thu, 22 May 2008 20:00:55 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14ubu (X11/20080502) MIME-Version: 1.0 To: heejin.jang@samsung.com References: <17085136.236881211466774482.JavaMail.weblogic@epml08> In-Reply-To: <17085136.236881211466774482.JavaMail.weblogic@epml08> X-Virus-Scanned: ClamAV using ClamSMTP Cc: Alexandru Petrescu , "mext@ietf.org" Subject: Re: [MEXT] hiopt (Revised text) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Looks good. Can you submit the modified draft? Jari Heejin Jang kirjoitti: > Hi, Jari and Vijay. > > I revised the draft as Jari's two comments. > Kindly see the below and give me your feedbacks. > > Thanks for your kind cooperation. :) > > * Modified points > > 1) The 3rd paragragh was modifed according to the Jari's 1st comment. > 2) For the 2nd comments, we allowed the Sub-opt-code 1 and mandated it in > a MIP6 Relay option. > > > 1> In Section 3.3 (Common Sub-options), page 9, > > Old: > > While the Sub-opt-code 1 is only available in both the requesting and > the returned Home Network Information options, Sub-opt-codes 2, 3, 4, > and 5 are available only in the returned Home Network Information > option and the MIP6 Relay Agent option. > > New: > > While the Sub-opt-codes 1, 2, 3, 4, and 5 are available in the MIP6 > Relay Agent option and the Home Network Information option returned > by the DHCP server, a value of 1 is the only Sub-opt-code available > in the requesting Home Network Information option by the mobile node. > > 2> In Section 4.2 (NAS/DHCP Relay Agent Behavior), page 13, 2nd paragraph, > > Old: > > The relay SHOULD include each home network > parameter in a sub-option, and include all sub-options in a single > MIP6 Relay Agent option. It MUST NOT include any sub-option whose > Sub-opt-code is other than 2, 3, 4, and 5 as described in Section > 3.3. > > New: > > (added paragraph) > When providing the home network information, the > relay MUST include a sub-option whose Sub-opt-code is 1, and set the > Home Network Parameter field to the FQDN of the network where the > home information is assigned. That FQDN information will be compared > with the target MSP requested by the mobile node when a DHCP server > searches for the matching information. > > The relay SHOULD include each home network parameter in a sub-option, > and include all sub-options in a single MIP6 Relay Agent option. It > MUST NOT include any sub-option whose Sub-opt-code is other than 1, > 2, 3, 4, and 5 as described in Section 3.3. > > 3> In Section 4.3 (DHCP Server Behavior), page 13, > > Old: > > The home network information > received from the relay SHOULD be kept in the server so that the > server can provide the information when it is requested by the mobile > node. > > The server MUST ignore any sub-option in a MIP6 Relay Agent option > whose Sub-opt-code is other than 2, 3, 4, and 5, as described in > Section 3.3. > > New: > > The MIP6 Relay Agent option which > does not include a sub-option with Sub-opt-code 1 MUST be ignored. > Otherwise, the home network information received from the relay > SHOULD be kept in the server so that the server can provide the > information when it is requested by the mobile node. > > The server MUST ignore any sub-option in a MIP6 Relay Agent option > whose Sub-opt-code is other than 1, 2, 3, 4, and 5, as described in > Section 3.3. > > 4> In page 14, case B, > > Old: > Any Home Network Information option which carries more than > one target MSP or which does not carry any target MSP MUST be > ignored. > > New: > > Any Home Network Information option which carries more than > one target MSP or which does not carry any target MSP MUST be > ignored. Otherwise, the DHCP server searches its database > by using the received target MSP as a key. > > 5> In page 15, the 8nd paragraph > > Old: > > The DHCP server should provide all of the matching home information > in Home Network Information option(s) based on its policy. It may > return partially matched results. For example, on receipt of a Home > Network Information option which specifies "xxx.example.com" as the > target network, it may return "example.com" to the mobile node. In > this case, "xxx.example.com" is returned in a sub-option with Sub- > opt-code 1, and "example.com" in a sub-option with Sub-opt-code 5. > Note that the detailed rule for returning partially matched instances > of home network information follows the server's own policy and is > outside the scope of this document. > > New: > > The DHCP server should provide all of the matching home information > in Home Network Information option(s) based on its policy. While > searching for the home network information by using the target MSP as > a key, it may return the results when the key is partially matched. > For example, on receipt of a Home Network Information option which > specifies "xxx.example.com" as the target network, it may return the > home network information assigned for "example.com" to the mobile > node. Note that the detailed rule for returning partially matched > instances of home network information follows the server's own policy > and is outside the scope of this document. > > 6> In Section 6 (IANA) > > Old: > o Home network identifier 1 > (only allowed in the Home Network > Information option; value Reserved > for the MIP6 Relay Agent option) > > New: > o Home network identifier 1 > > > Thanks for your kind help. > > - All the best > heejin. > > > ------- Original Message ------- > Sender : Jari Arkko > Date : 2008-05-20 01:12 (GMT+09:00) > Title : hiopt > > Hi all, > > I have reviewed this thread and re-reviewed the draft. While I > sympathize with some of the questions Alex had, I see no technical > reason to block the draft from being approved, and I see no support from > the WG from doing this either. So I am now approving the document. > > However, as a re-read the draft, I also noticed two additional issues. > The first issue is that Section 3 seems to be forgetting the case where > DHCP server has no information about a particular home network. Due to > this, I would like to make the following change: > > OLD: > In a network where the NAS is not co- > located with a DHCP relay nor a server, the server may not be > provided with the home network information from the NAS, and thereby > it may assign to a mobile node the home information which has been > preconfigured by the administrator or which is acquired through a > mechanism that is not described in this document. > NEW: > In a network where the NAS is not co- > located with a DHCP relay nor a server, the server may not be > provided with the home network information from the NAS, and thereby > it may either fail to provide information, or provide home information > which has been preconfigured by the administrator or which is acquired > through a mechanism that is not described in this document. > > Secondly, Section 4.2 and 4.3 talk about how relays can provide > information to servers. But I cannot see how the server knows which > piece of information from the relay corresponds to what Home Information > Option, in case there were multiple options with different home network > names. I am a bit uncertain how to fix this, however. Perhaps it is > necessary to allow suboption type 1 in relay agent options, too. > > Please suggest text, and I will place it in the RFC Editor note part of > the tracker and approve it. (Or you can submit a new version with these > fixes.) > > Jari > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 22 19:03:55 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 674483A6B7A; Thu, 22 May 2008 19:03:55 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8048D3A6A98 for ; Thu, 22 May 2008 19:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.811 X-Spam-Level: X-Spam-Status: No, score=-3.811 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZ40l5F81agQ for ; Thu, 22 May 2008 19:03:48 -0700 (PDT) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by core3.amsl.com (Postfix) with ESMTP id 2EBA13A6C19 for ; Thu, 22 May 2008 19:02:57 -0700 (PDT) Received: from ep_ms5_bk (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K1A00JJ1T6F00@mailout3.samsung.com> for mext@ietf.org; Fri, 23 May 2008 10:51:51 +0900 (KST) Received: from ep_spt01 (ms5.samsung.com [203.254.225.113]) by ms5.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K1A00DJ9T6FXZ@ms5.samsung.com> for mext@ietf.org; Fri, 23 May 2008 10:51:51 +0900 (KST) Content-return: prohibited Date: Fri, 23 May 2008 01:51:51 +0000 (GMT) From: Heejin Jang To: Frank Xia Message-id: <17419739.253631211507511649.JavaMail.weblogic@epml12> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20080523014752721@heejin.jang X-MTR: 20080523014752721@heejin.jang X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML Cc: "mext@ietf.org" Subject: Re: [MEXT] hiopt (Revised text) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: heejin.jang@samsung.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, Frank. That issue was discussed in March and April, but AD (Jari) recommends that the draft cover discovery of Mobile IPv6 home agents that have an IPv4 address, but NOT Mobile IPv4. Thanks for your consideration. :) -Best regards, Heejin ------- Original Message ------- Sender : Frank Xia Date : 2008-05-23 00:03 (GMT+09:00) Title : Re: [MEXT] hiopt (Revised text) Hi Heejin In this draft, a MN uses DHCPv6 to acquire home network information. However, if MN only has IPv4 CoA in DSMIPv6 scenario, IMO, DHCPv4 support is needed. What is your opinion? BR Frank ----- Original Message ----- From: Heejin Jang To: Jari Arkko Cc: Alexandru Petrescu ; mext@ietf.org Sent: Thursday, May 22, 2008 9:32 AM Subject: Re: [MEXT] hiopt (Revised text) Hi, Jari and Vijay. I revised the draft as Jari's two comments. Kindly see the below and give me your feedbacks. Thanks for your kind cooperation. :) * Modified points 1) The 3rd paragragh was modifed according to the Jari's 1st comment. 2) For the 2nd comments, we allowed the Sub-opt-code 1 and mandated it in a MIP6 Relay option. 1> In Section 3.3 (Common Sub-options), page 9, Old: While the Sub-opt-code 1 is only available in both the requesting and the returned Home Network Information options, Sub-opt-codes 2, 3, 4, and 5 are available only in the returned Home Network Information option and the MIP6 Relay Agent option. New: While the Sub-opt-codes 1, 2, 3, 4, and 5 are available in the MIP6 Relay Agent option and the Home Network Information option returned by the DHCP server, a value of 1 is the only Sub-opt-code available in the requesting Home Network Information option by the mobile node. 2> In Section 4.2 (NAS/DHCP Relay Agent Behavior), page 13, 2nd paragraph, Old: The relay SHOULD include each home network parameter in a sub-option, and include all sub-options in a single MIP6 Relay Agent option. It MUST NOT include any sub-option whose Sub-opt-code is other than 2, 3, 4, and 5 as described in Section 3.3. New: (added paragraph) When providing the home network information, the relay MUST include a sub-option whose Sub-opt-code is 1, and set the Home Network Parameter field to the FQDN of the network where the home information is assigned. That FQDN information will be compared with the target MSP requested by the mobile node when a DHCP server searches for the matching information. The relay SHOULD include each home network parameter in a sub-option, and include all sub-options in a single MIP6 Relay Agent option. It MUST NOT include any sub-option whose Sub-opt-code is other than 1, 2, 3, 4, and 5 as described in Section 3.3. 3> In Section 4.3 (DHCP Server Behavior), page 13, Old: The home network information received from the relay SHOULD be kept in the server so that the server can provide the information when it is requested by the mobile node. The server MUST ignore any sub-option in a MIP6 Relay Agent option whose Sub-opt-code is other than 2, 3, 4, and 5, as described in Section 3.3. New: The MIP6 Relay Agent option which does not include a sub-option with Sub-opt-code 1 MUST be ignored. Otherwise, the home network information received from the relay SHOULD be kept in the server so that the server can provide the information when it is requested by the mobile node. The server MUST ignore any sub-option in a MIP6 Relay Agent option whose Sub-opt-code is other than 1, 2, 3, 4, and 5, as described in Section 3.3. 4> In page 14, case B, Old: Any Home Network Information option which carries more than one target MSP or which does not carry any target MSP MUST be ignored. New: Any Home Network Information option which carries more than one target MSP or which does not carry any target MSP MUST be ignored. Otherwise, the DHCP server searches its database by using the received target MSP as a key. 5> In page 15, the 8nd paragraph Old: The DHCP server should provide all of the matching home information in Home Network Information option(s) based on its policy. It may return partially matched results. For example, on receipt of a Home Network Information option which specifies "xxx.example.com" as the target network, it may return "example.com" to the mobile node. In this case, "xxx.example.com" is returned in a sub-option with Sub- opt-code 1, and "example.com" in a sub-option with Sub-opt-code 5. Note that the detailed rule for returning partially matched instances of home network information follows the server's own policy and is outside the scope of this document. New: The DHCP server should provide all of the matching home information in Home Network Information option(s) based on its policy. While searching for the home network information by using the target MSP as a key, it may return the results when the key is partially matched. For example, on receipt of a Home Network Information option which specifies "xxx.example.com" as the target network, it may return the home network information assigned for "example.com" to the mobile node. Note that the detailed rule for returning partially matched instances of home network information follows the server's own policy and is outside the scope of this document. 6> In Section 6 (IANA) Old: o Home network identifier 1 (only allowed in the Home Network Information option; value Reserved for the MIP6 Relay Agent option) New: o Home network identifier 1 Thanks for your kind help. - All the best heejin. ------- Original Message ------- Sender : Jari Arkko Date : 2008-05-20 01:12 (GMT+09:00) Title : hiopt Hi all, I have reviewed this thread and re-reviewed the draft. While I sympathize with some of the questions Alex had, I see no technical reason to block the draft from being approved, and I see no support from the WG from doing this either. So I am now approving the document. However, as a re-read the draft, I also noticed two additional issues. The first issue is that Section 3 seems to be forgetting the case where DHCP server has no information about a particular home network. Due to this, I would like to make the following change: OLD: In a network where the NAS is not co- located with a DHCP relay nor a server, the server may not be provided with the home network information from the NAS, and thereby it may assign to a mobile node the home information which has been preconfigured by the administrator or which is acquired through a mechanism that is not described in this document. NEW: In a network where the NAS is not co- located with a DHCP relay nor a server, the server may not be provided with the home network information from the NAS, and thereby it may either fail to provide information, or provide home information which has been preconfigured by the administrator or which is acquired through a mechanism that is not described in this document. Secondly, Section 4.2 and 4.3 talk about how relays can provide information to servers. But I cannot see how the server knows which piece of information from the relay corresponds to what Home Information Option, in case there were multiple options with different home network names. I am a bit uncertain how to fix this, however. Perhaps it is necessary to allow suboption type 1 in relay agent options, too. Please suggest text, and I will place it in the RFC Editor note part of the tracker and approve it. (Or you can submit a new version with these fixes.) Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From ca@radio100fm.dk Thu May 22 19:35:34 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00AE93A6BA9; Thu, 22 May 2008 19:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -76.157 X-Spam-Level: X-Spam-Status: No, score=-76.157 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, HELO_DYNAMIC_IPADDR2=4.395, J_CHICKENPOX_24=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJ54KdaIqnMR; Thu, 22 May 2008 19:35:29 -0700 (PDT) Received: from 201-255-150-17.mrse.com.ar (unknown [201.255.150.17]) by core3.amsl.com (Postfix) with SMTP id 2D76C3A693A; Thu, 22 May 2008 19:35:12 -0700 (PDT) X-Originating-IP: 240.116.37.230 by smtp.201.255.150.17; Thu, 22 May 2008 22:35:12 -0500 Message-ID: From: "Troy Goode" Reply-To: "Troy Goode" To: msec-archive@ietf.org Subject: Get one of these awesome replicas Date: Thu, 22 May 2008 22:35:12 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit X-Antivirus: avast! (VPS 080522-0, 22/05/2008), Outbound message X-Antivirus-Status: Clean A Bvlgari watch is an extraordinary masterpiece that is born from the marriage of watch making and jewelry expertise. Only the most discriminating and sophisticated watch users dare put a Bv1gari on their wrists, but once the metal touches their skin, they are bound forever... How would you like to become one of the lucky few that have experienced the pleasure of sporting a Bvlgari timepiece? Now you can, and at a very reduced cost! Prestige Replicas offers a tremendous collection of Bvlgari replicas starting just a little above $200... So now there is no reason why you can't have your very own Bvlgari today! http://natyxycudiz50.blogspot.com/ From mext-bounces@ietf.org Thu May 22 19:49:27 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70D753A6BD4; Thu, 22 May 2008 19:49:27 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BE6E3A6BB7 for ; Thu, 22 May 2008 19:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WI8BN-PYVaw2 for ; Thu, 22 May 2008 19:49:25 -0700 (PDT) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by core3.amsl.com (Postfix) with ESMTP id B22693A6BA9 for ; Thu, 22 May 2008 19:49:24 -0700 (PDT) Received: from ep_ms5_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K1A0065CVG7TA@mailout2.samsung.com> for mext@ietf.org; Fri, 23 May 2008 11:40:55 +0900 (KST) Received: from ep_spt01 (ms5.samsung.com [203.254.225.113]) by ms5.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K1A00KF8VG7FG@ms5.samsung.com> for mext@ietf.org; Fri, 23 May 2008 11:40:55 +0900 (KST) Content-return: prohibited Date: Fri, 23 May 2008 02:40:55 +0000 (GMT) From: Heejin Jang To: Heejin Jang , Frank Xia , "mext@ietf.org" Message-id: <23113373.254601211510455515.JavaMail.weblogic@epml10> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20080523022922063@heejin.jang X-MTR: 20080523022922063@heejin.jang X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML Subject: [MEXT] Fwd: Re: Re: hiopt (Revised text) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: heejin.jang@samsung.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Oh, I misunderstood your question. DHCPv4 issue has been proposed and discussed in last month, too but AD mentioned that we put the dhcpv4 side out for the moment at that time. The hiopt draft aims at supporting IPv4/IPv6 HoA in the IPv6 networks(with DHCPv6). IMO, I don't think it is a good idea to handle DHCPv4 and DHCPv6 cases in a single document because the specific DHCPv4 messages & procedures are different from those of DHCPv6 though the concept is similar. Thanks for your concerns. - Regards, Heejin. ------- Original Message ------- Sender : Heejin Jang R&D Staff Member/Communication & Networking Lab/Samsung Advanced Institute of Technology Date : 2008-05-23 10:51 (GMT+09:00) Title : Re: Re: [MEXT] hiopt (Revised text) Hi, Frank. That issue was discussed in March and April, but AD (Jari) recommends that the draft cover discovery of Mobile IPv6 home agents that have an IPv4 address, but NOT Mobile IPv4. Thanks for your consideration. :) -Best regards, Heejin ------- Original Message ------- Sender : Frank Xia Date : 2008-05-23 00:03 (GMT+09:00) Title : Re: [MEXT] hiopt (Revised text) Hi Heejin In this draft, a MN uses DHCPv6 to acquire home network information. However, if MN only has IPv4 CoA in DSMIPv6 scenario, IMO, DHCPv4 support is needed. What is your opinion? BR Frank ----- Original Message ----- From: Heejin Jang To: Jari Arkko Cc: Alexandru Petrescu ; mext@ietf.org Sent: Thursday, May 22, 2008 9:32 AM Subject: Re: [MEXT] hiopt (Revised text) Hi, Jari and Vijay. I revised the draft as Jari's two comments. Kindly see the below and give me your feedbacks. Thanks for your kind cooperation. :) * Modified points 1) The 3rd paragragh was modifed according to the Jari's 1st comment. 2) For the 2nd comments, we allowed the Sub-opt-code 1 and mandated it in a MIP6 Relay option. 1> In Section 3.3 (Common Sub-options), page 9, Old: While the Sub-opt-code 1 is only available in both the requesting and the returned Home Network Information options, Sub-opt-codes 2, 3, 4, and 5 are available only in the returned Home Network Information option and the MIP6 Relay Agent option. New: While the Sub-opt-codes 1, 2, 3, 4, and 5 are available in the MIP6 Relay Agent option and the Home Network Information option returned by the DHCP server, a value of 1 is the only Sub-opt-code available in the requesting Home Network Information option by the mobile node. 2> In Section 4.2 (NAS/DHCP Relay Agent Behavior), page 13, 2nd paragraph, Old: The relay SHOULD include each home network parameter in a sub-option, and include all sub-options in a single MIP6 Relay Agent option. It MUST NOT include any sub-option whose Sub-opt-code is other than 2, 3, 4, and 5 as described in Section 3.3. New: (added paragraph) When providing the home network information, the relay MUST include a sub-option whose Sub-opt-code is 1, and set the Home Network Parameter field to the FQDN of the network where the home information is assigned. That FQDN information will be compared with the target MSP requested by the mobile node when a DHCP server searches for the matching information. The relay SHOULD include each home network parameter in a sub-option, and include all sub-options in a single MIP6 Relay Agent option. It MUST NOT include any sub-option whose Sub-opt-code is other than 1, 2, 3, 4, and 5 as described in Section 3.3. 3> In Section 4.3 (DHCP Server Behavior), page 13, Old: The home network information received from the relay SHOULD be kept in the server so that the server can provide the information when it is requested by the mobile node. The server MUST ignore any sub-option in a MIP6 Relay Agent option whose Sub-opt-code is other than 2, 3, 4, and 5, as described in Section 3.3. New: The MIP6 Relay Agent option which does not include a sub-option with Sub-opt-code 1 MUST be ignored. Otherwise, the home network information received from the relay SHOULD be kept in the server so that the server can provide the information when it is requested by the mobile node. The server MUST ignore any sub-option in a MIP6 Relay Agent option whose Sub-opt-code is other than 1, 2, 3, 4, and 5, as described in Section 3.3. 4> In page 14, case B, Old: Any Home Network Information option which carries more than one target MSP or which does not carry any target MSP MUST be ignored. New: Any Home Network Information option which carries more than one target MSP or which does not carry any target MSP MUST be ignored. Otherwise, the DHCP server searches its database by using the received target MSP as a key. 5> In page 15, the 8nd paragraph Old: The DHCP server should provide all of the matching home information in Home Network Information option(s) based on its policy. It may return partially matched results. For example, on receipt of a Home Network Information option which specifies "xxx.example.com" as the target network, it may return "example.com" to the mobile node. In this case, "xxx.example.com" is returned in a sub-option with Sub- opt-code 1, and "example.com" in a sub-option with Sub-opt-code 5. Note that the detailed rule for returning partially matched instances of home network information follows the server's own policy and is outside the scope of this document. New: The DHCP server should provide all of the matching home information in Home Network Information option(s) based on its policy. While searching for the home network information by using the target MSP as a key, it may return the results when the key is partially matched. For example, on receipt of a Home Network Information option which specifies "xxx.example.com" as the target network, it may return the home network information assigned for "example.com" to the mobile node. Note that the detailed rule for returning partially matched instances of home network information follows the server's own policy and is outside the scope of this document. 6> In Section 6 (IANA) Old: o Home network identifier 1 (only allowed in the Home Network Information option; value Reserved for the MIP6 Relay Agent option) New: o Home network identifier 1 Thanks for your kind help. - All the best heejin. ------- Original Message ------- Sender : Jari Arkko Date : 2008-05-20 01:12 (GMT+09:00) Title : hiopt Hi all, I have reviewed this thread and re-reviewed the draft. While I sympathize with some of the questions Alex had, I see no technical reason to block the draft from being approved, and I see no support from the WG from doing this either. So I am now approving the document. However, as a re-read the draft, I also noticed two additional issues. The first issue is that Section 3 seems to be forgetting the case where DHCP server has no information about a particular home network. Due to this, I would like to make the following change: OLD: In a network where the NAS is not co- located with a DHCP relay nor a server, the server may not be provided with the home network information from the NAS, and thereby it may assign to a mobile node the home information which has been preconfigured by the administrator or which is acquired through a mechanism that is not described in this document. NEW: In a network where the NAS is not co- located with a DHCP relay nor a server, the server may not be provided with the home network information from the NAS, and thereby it may either fail to provide information, or provide home information which has been preconfigured by the administrator or which is acquired through a mechanism that is not described in this document. Secondly, Section 4.2 and 4.3 talk about how relays can provide information to servers. But I cannot see how the server knows which piece of information from the relay corresponds to what Home Information Option, in case there were multiple options with different home network names. I am a bit uncertain how to fix this, however. Perhaps it is necessary to allow suboption type 1 in relay agent options, too. Please suggest text, and I will place it in the RFC Editor note part of the tracker and approve it. (Or you can submit a new version with these fixes.) Jari _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From taxrefund@2x7c.1xdb59d1.irs.gov Thu May 22 20:38:08 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C2A23A6B9B for ; Thu, 22 May 2008 20:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -88.611 X-Spam-Level: X-Spam-Status: No, score=-88.611 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_PAST_12_24=0.992, FORGED_MUA_OUTLOOK=3.116, MSOE_MID_WRONG_CASE=0.82, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, SARE_HEXOCTDWORD=2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpzK3R7-jkXu for ; Thu, 22 May 2008 20:38:07 -0700 (PDT) Received: from s15269609.onlinehome-server.info (s15269609.onlinehome-server.info [87.106.179.204]) by core3.amsl.com (Postfix) with ESMTP id E55B23A6995 for ; Thu, 22 May 2008 20:38:03 -0700 (PDT) Received: (qmail 5003 invoked from network); 22 May 2008 17:50:44 +0200 Received: from unknown (HELO service) (24.80.224.209) by s15269609.onlinehome-server.info with SMTP; 22 May 2008 17:50:44 +0200 Reply-To: taxrefund@2x7c.1xdb59d1.irs.gov From: Internal Revenue Service (IRS) Subject: Tax Notification Date: Wed, 21 May 2008 20:49:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20080523033806.E55B23A6995@core3.amsl.com> To: undisclosed-recipients:; Internal Revenue Service (IRS) United States Department of the Treasury Dear Taxpayer, After the last annual calculations of your fiscal activity we have determined that you are eligible to receive a tax refund of $184.80. Please submit the tax refund request and allow us 6-9 days in order to process it. A refund can be delayed for a variety of reasons. For example submitting invalid records or applying after the deadline. To access the form for your tax refund, use the following personalized link: http://0x7C.0xDB11D1/www.irs.gov/ Regards, Internal Revenue Service Document Reference: (0x7C.0xDB11D1). From mext-bounces@ietf.org Sun May 25 05:15:07 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 416623A6A2C; Sun, 25 May 2008 05:15:06 -0700 (PDT) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0794B3A6A2C; Sun, 25 May 2008 05:15:03 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080525121504.0794B3A6A2C@core3.amsl.com> Date: Sun, 25 May 2008 05:15:03 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-nemo-v4traversal-03.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Mobile IPv6 Support for Dual Stack Hosts and Routers Author(s) : H. Soliman Filename : draft-ietf-mext-nemo-v4traversal-03.txt Pages : 48 Date : 2008-05-25 The current Mobile IPv6 and NEMO specifications support IPv6 only. This specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the home agent. This specification also allows the Mobile Node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path between the mobile node and its home agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-v4traversal-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-mext-nemo-v4traversal-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-25050149.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --NextPart-- From c.germak@artsgazette.com Sun May 25 21:20:12 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C92D63A6B0C; Sun, 25 May 2008 21:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -34.442 X-Spam-Level: X-Spam-Status: No, score=-34.442 tagged_above=-999 required=5 tests=[AWL=-41.715, BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_IPADDR2=4.395, HTTP_ESCAPED_HOST=0.134, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfoQkyQzkUz3; Sun, 25 May 2008 21:20:06 -0700 (PDT) Received: from 201-255-121-108.mrse.com.ar (unknown [201.255.121.108]) by core3.amsl.com (Postfix) with SMTP id 9EF623A6895; Sun, 25 May 2008 21:19:53 -0700 (PDT) X-Originating-IP: 84.210.8.248 by smtp.201.255.121.108; Mon, 26 May 2008 00:20:07 -0500 Message-ID: From: "Marion Schultz" Reply-To: "Marion Schultz" To: msec-archive@ietf.org Subject: New replica watches delivered fast Date: Mon, 26 May 2008 00:20:07 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Tag Heuer watch is a luxury statement on its own. Unfortunately, that luxury comes with a price... Except when you visit Prestige Replicas, the web's most comprehensive collection of brand name replica watches. In Prestige Replicas, any Tag Heuer is available for just over $200. http://www%2Eshheus%2Ecom/ For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Prestige Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Prestige Replicas. http://www%2Eshheus%2Ecom/ From kansas_@datafull.com Sun May 25 22:34:26 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2AEA3A6847; Sun, 25 May 2008 22:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.944 X-Spam-Level: * X-Spam-Status: No, score=1.944 tagged_above=-999 required=5 tests=[AWL=2.369, BAYES_00=-2.599, DNS_FROM_AHBL_RHSBL=0.692, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGmTOvRRZNAP; Sun, 25 May 2008 22:34:21 -0700 (PDT) Received: from avas-mr20.fibertel.com.ar (avas-mr20.fibertel.com.ar [24.232.0.123]) by core3.amsl.com (Postfix) with ESMTP id 2757B3A682E; Sun, 25 May 2008 22:34:21 -0700 (PDT) Received: from 176-6-245-190.fibertel.com.ar ([190.245.6.176]:2528 "EHLO desktop" smtp-auth: "directodefabrica" rhost-flags-OK-FAIL-OK-FAIL) by avas-mr20.fibertel.com.ar with ESMTPA id S1016515AbYEZFeS convert rfc822-to-8bit; Mon, 26 May 2008 02:34:18 -0300 Message-ID: <380-22008512653414671@desktop> To: "kansas dvds" Reply-To: "kansas@datafull.com" From: "kansas@datafull.com" Subject: KANSAS DVDs 20 de MAYO Date: Mon, 26 May 2008 07:34:14 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-Fib-Al-Info: Al X-Fib-Al-MRId: 52f6d5c91449e584976926d9ec264217 X-Fib-Al: noav X-Fib-Al-SA: analyzed X-Fib-Al-From: kansas_@datafull.com KANSAS DVDs kansas@datafull.com DVD con portada color y caja DVD $8 cada uno 10 unidades $7 cada uno 20 unidades $6,5 cada uno 50 unidades $6 cada uno 100 unidades $5 cada uno DVDs en sobre: 10 unidades $5 cada uno 20 unidades $4,25 cada uno 50 unidades $3,5 cada uno 100 unidades $2,5 cada uno 1364 Bee Movie 1365 La Mujer de Mis Pesadillas (con Ben Stiller) 1366 Asesinato de Jeese James 1367 Supercool 1368 El Reino 1369 Ligeramente Embarazada 1370 Resident Evil 3 1371 Susurro de Terror 1372 Licencia para Casarse 1373 El Sospechoso 1374 BeoWulf 1375 El Vidente 1376 El Arca 1377 Justicia a Cualquier Precio 1378 Casper 1379 En Nombre del Odio 1380 Sin Reservas 1381 Mimzy 1382 Juego de Gemelas 1383 Padrinos Magicos: Abra Catastrofe 1384 Baby Einstein: Un dia en la Granja 1385 Dinero de Sangre 1386 Infidelidad y Romance 1387 Acorralados Solicitar lista completa kansas@datafull.com Ante cualquier duda avisame por este medio Saluda atentamente   Daniel Lomas Kansas DVDs kansas@datafull.com From bibliotecavenezuelainforma@iica.int Mon May 26 05:54:03 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FD9C3A69FC for ; Mon, 26 May 2008 05:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.926 X-Spam-Level: X-Spam-Status: No, score=-5.926 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HELO_EQ_IT=0.635, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_FROM_DRUGS=1.666, SUBJ_ALL_CAPS=2.077, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhANbYIAxYkE for ; Mon, 26 May 2008 05:54:03 -0700 (PDT) Received: from ppp-82-84-212-67.cust-adsl.tiscali.it (unknown [82.84.212.67]) by core3.amsl.com (Postfix) with SMTP id 605433A6A0C for ; Mon, 26 May 2008 05:54:01 -0700 (PDT) Message-Id: <20080526035406.8793.qmail@ppp-82-84-212-67.cust-adsl.tiscali.it> To: Subject: RE: SALE 89% OFF From: VIAGRA INC MIME-Version: 1.0 Content-Type: text/html Date: Mon, 26 May 2008 05:54:01 -0700 (PDT)
From c.fleming@falconerstewart.co.uk Mon May 26 21:44:17 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82FDF3A67EA; Mon, 26 May 2008 21:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.76 X-Spam-Level: X-Spam-Status: No, score=-4.76 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, HTTP_ESCAPED_HOST=0.134, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9vYZzVB88Oa; Mon, 26 May 2008 21:44:10 -0700 (PDT) Received: from 97-133-223-201.adsl.terra.cl (97-133-223-201.adsl.terra.cl [201.223.133.97]) by core3.amsl.com (Postfix) with SMTP id 600EB3A6858; Mon, 26 May 2008 21:43:32 -0700 (PDT) X-Originating-IP: 248.92.70.172 by smtp.201.223.133.97; Tue, 27 May 2008 00:43:47 -0500 Message-ID: From: "Ava Bunch" Reply-To: "Ava Bunch" To: msec-archive@ietf.org Subject: Replica watches make great gifts Date: Tue, 27 May 2008 00:43:47 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Everybody knows that a Cartier watch is a silent statement of wealth and luxury. But we all know as well that the price of putting one of them on your wrist is for the most unaffordable by the average Joe. That's why replica Cartier watches are becoming more and more popular by the day. They're actually the affordable solution to this dilemma. And thanks to the internet, there is now a place where the highest quality Cartier replicas are available: Prestige Replicas. So, why not take a look at the extensive inventory that this site has to offer? After all, browsing through their hundreds of Cartier watches is absolutely free, and buying the one of your dreams is simply inexpensive. http://www%2Esuppoenn%2Ecom/ From mext-bounces@ietf.org Mon May 26 21:52:03 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 251C93A6858; Mon, 26 May 2008 21:52:03 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B18883A6858 for ; Mon, 26 May 2008 21:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rzu24d48JdFj for ; Mon, 26 May 2008 21:52:00 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by core3.amsl.com (Postfix) with ESMTP id CA6A53A67EA for ; Mon, 26 May 2008 21:52:00 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id k34so2653981wah.25 for ; Mon, 26 May 2008 21:52:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; bh=yx2lTojn32nmIwFlyXrwkvTWCnPAi7ZGwEAmRQzBH4I=; b=V7buRMT96orNm/b2hwpjpe2Y1mmYsuC886w4rIkzRpg59PBkEzRkukOUZbY1hIieXYixglL8zciCPLE2oCiMIIhLLbIsm5eMFMFbmVvjrYmG2qOTi8yXRftCXAyvGMuTqJeHekiknbGxDbtWRdv1Y1kMU9g/HCY5wBp69J41W0M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; b=MNkPmdF7FF8YOV3T+9/VLUgU+3PKd2k57gl6zPqpW+Xr3uGYxnNw9p0ag1mOekxyK9g6tBN6h67koK4Gl9aBusGSEOH3qt59QiikiOFNx2ClWrTi2MDfQzEx/C8YI6q3cU8uWi1quCcgrU/OsAsAhDXPusFqmOEG0pMh4p+iCbE= Received: by 10.115.14.1 with SMTP id r1mr892721wai.139.1211863923097; Mon, 26 May 2008 21:52:03 -0700 (PDT) Received: from EM60-254-223-26.pool.e-mobile.ne.jp ( [60.254.223.26]) by mx.google.com with ESMTPS id k37sm20531213waf.31.2008.05.26.21.51.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 26 May 2008 21:52:02 -0700 (PDT) From: Ryuji Wakikawa To: chanwah.ng@sg.panasonic.com In-Reply-To: <1209786547.6310.17.camel@localhost> References: <20080430013001.6B3FA3A6C64@core3.amsl.com> <481858A0.20102@it.uc3m.es> <1209786547.6310.17.camel@localhost> Message-Id: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 27 May 2008 13:51:45 +0900 X-Mailer: Apple Mail (2.919.2) Cc: mext Subject: Re: [MEXT] WGLC for draft-ietf-monami6-multiplecoa-07.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Chan-Wah Thanks for detailed comments. All your comments are editorial and clarification. We can easily fix your comments. Thanks again. Some comments are below. On 2008/05/03, at 12:49, Chan-Wah Ng wrote: > > On Wed, 2008-04-30 at 13:31 +0200, marcelo bagnulo braun wrote: >> Hi, >> >> This is the WGLC for draft-ietf-monami6-multiplecoa-07.txt. Please >> check >> if all the issues that were raised have been addressed in this new >> version. If you have issues with the document, please raise them. >> If you >> are ok with the document and you think it should be sent to the ISEG, >> please also say so. Provide comments till may 14. >> For your convinience, the document can be found at: >> >> Title : Multiple Care-of Addresses Registration >> Author(s) : R. Wakikawa, et al. >> Filename : draft-ietf-monami6-multiplecoa-07.txt >> Pages : 44 >> Date : 2008-04-29 >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-07.txt >> > > Hello, > > following is my review on the first 7 sections of the draft. > > --- > > [Section 1 - Pg 5] > > The first paragraph explained the motivation for this work, but failed > to reference the other WG document on the analysis of why MIPv6 cannot > fulfill such motivation. I would add in some text as follows: > > > A mobile node may use various types of network interfaces to obtain > durable and wide area network connectivity. This is increasingly > become true with mobile nodes having multiple interfaces such as > 802.2, 802.11, 802.16, cellular radios, etc.. The motivations for > and benefits of using multiple points of attachment are discussed in > [ID-MOTIVATION]. When a mobile node with multiple interfaces uses > Mobile IPv6 [RFC-3775] for mobility management, it cannot use its > multiple interfaces to send and receive packets while taking > advantage of session continuity provided by Mobile IPv6. This is > because Mobile IPv6 allows the mobile node to only bind one care-of > address at a time with its home address. > > > See [ID-MIP6ANALYSIS] on a further analysis of using multiple > interfaces and addresses with Mobile IPv6. > Right. I will add this reference. > > > ---- > > [Section 2 - Pg 6] > > Binding Identification number (BID) > > The BID ... > ... Zero and negative values MUST NOT be used. > > This is strange ... BID is defined as unsigned 16 bit integer ... how > can negative values be used? What is the meaning of "negative values" > here? Note same comment applies to [Section 5.1, pg 16]. ok > > > Bulk Registration > > A mobile node can register multiple bindings at once by sending a > single Binding Update. A mobile node can also replace some or > all > the bindings available at the home agent with the new bindings by > using the bulk registration. Bulk registration is supported only > for home registration (i.e. with the home agent) as explained in > Section 5.4. A mobile node MUST NOT perform bulk registration > with a correspondent node. > > The last part seems to be too strong ... the only reason why an MN > should not perform bulk registration IMHO is because this > specification > does not want to support it "for protocol simplicity". Simply say so > like changing the last sentence to "Bulk registration with a > correpondent node is not supported in this specification." Saying MN > "MUST NOT" seems to suggest there is a strong security or protocol > design reason for MN not to do so which is not explained -- the only > reason stated is in pg 7: This specification isn't designed to perform bulk registration to CN. We need to prohibit this, right? > .... For protocol > simplicity, bulk registration to correspondent nodes is not > supported > in this document. This is because the Return Routability mechanism > introduced in [RFC-3775] cannot be easily extended to verify > multiple > care-of addresses stored in a single Binding Update. > > This, IMHO, does not justify the use of a strong "MUST NOT". Here are the definition from RFC2119. 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. I still think "MUST NOT" is appropriate here. Bulk registration specified in this doc has no mechanism to verify the CoAs. RR cannot not protect all the CoAs. Other separate document can specify the bulk registration for CN later. > --- > > [Section 3 - Pg 7] > > Editorial -- plural/singular mismatch: > > Figure 1 illustrates the configuration where the mobile node obtains > multiple care-of addresses at foreign links. The mobile node can > utilize all the care-of address. In Figure 1, the home address of > ^^^^^^^ addresses thanks:-) > --- > > [ Section 4.2 - Pg 12-14] > > 4.2. Binding Identifier Mobility Option > > Typically for new options defined, the byte alignment should be > specified. This may get a bit tricky, though, since depending on > whether Care-of Address field is present or not, and what kind of > care-of address, the byte alignment requirement will change. > > ... > > Status > > When the Binding Identifier mobility option is included in a > Binding Acknowledgement, this field overwrites the status field > in > the Binding Acknowledgement. If this field is zero, the receiver > MUST use the registration status stored in the Binding > Acknowledgement message. This Status field is also used to carry > error information related to the care-of address test in the > Care-of Test message. The status is 8-bit unsigned integer. The > possible status codes are the same as the status codes of Binding > Acknowledgement. > > What happens to this field when the option is included in the Binding > Update message? Should it be set to zero, and ignored by the receiver > or what? Should be set to zero. However, the receiver ignores this field if the option is carried with BU. > > > ... > > Reserved > > 5 bits Reserved field. The reserved field MUST be zero. > > Typically, a spec would mandate sender to set reserved bit to 0 and > response of receiver if the bits are non-zero -- so should the > receiver > silently ignore the bits, silently discard the BU, reply with Binding > Error, or what? There is no reason to reject the BU only because the reserved field is not zero. > > > --- > > Care-of Address > > This field has the variable length depending on the specified > flags. Either IPv4 or IPv6 care-of address for the corresponding > BID can be stored in this field. This field MUST NOT be used > if a > Binding Identifier mobility option is included in any other > message other than a Binding Update. > > > The description of this field leaves me wondering. Firstly, > "depending > on the specified flags." What flags? Whose flags? There are only > two right. This is old text. According to George's comment, we removed the flags. Will fix this. > flags in this option, H and O. None seems to affect the length of > this > field. A more precise description should be given here. Secondly, > "This field MUST NOT be used ... in any other message other than a > Binding Update". What is the meaning of must not be used? Does it > means that this field is still there in a BA? Should the field > becomes > a zero-length field in BA or should it be set to zero and ignored by > receiver? Or if the field is not there, i.e. the Length field is 8, this field is appeared only when a CoA address value is presented. > > then this field can be omitted in this option (which is the case based > on later sections). Some text here should describe it clearly here. > Answering this question also goes back to the question of byte > alignment > for this BID option. > > > --- > > [Section 4.3 - pg 14 to 15] > > MCOA NOTCOMPLETE (TBD < 128) > MCOA RETURNHOME WO/NDP (TBD < 128) > MCOA MALFORMED (TBD more than 128) > MCOA BID CONFLICT (TBD more than 128) > ... > > Editorial -- you used "TBD < 128" but use "TBD more than 128". Better > to be consistent. Ok. > > > --- > > [Section 5.3, pg 17] > > IPv6 header (src=CoA, dst=HA) > IPv6 Home Address Option > ESP Header (for home registration) > Mobility header > -Binding Update > Mobility Options > - Binding Identifier mobility option > - Binding Authorization mobility option > (for Route Optimization) > > Figure 6: Binding Update for Binding Registration > > > Figure 6 uses parenthesis in inconsistent ways. The first line, IPv6 > Header, it is used to display the contents; subsequently, it is used > to > indicate the conditions for the relevant contents to be there. I > would > instead suggest you break the figure into two, one for BU sent to HA, > and one for BU sent to CN, thereby eliminating the need for subsequent > parenthesis. Also, the use "-" as bullets can be omitted. > > --- > > [Section 5.5, pg 18] > > .... The care-of addresses field in each mobility > option SHOULD be omitted by the sender and MUST be ignored by the > receiver. This is because the receiver will remove the binding that > matches the specified BID. > > Similar to previous comment in Section 4.2, what is the meaning of > "should be ommitted"? The filed is there or not? The field is not there. > > > --- > > [Section 6.1, pg 27] > > Apart from the first paragraph, the section seems to concentrate > only on > correspondent node. I think the description fits both the > correspondent > node and home agent. Thus, the terminology used should be corrected > (either replace "correspondent node" with "correspondent node or home > agent", or create a term such as "correspondent entity" as per RFC > 4889, > "recipient", or even "the node" as used in later part of Sect 5). ok > > --- > > [Section 6.3, pg 28] > > o When the Length value is either 12 or 20, the care-of address > MUST > be present in the Binding Identifier mobility option. If the > care-of address is not present, the receiver MUST reject the > Binding Identifier mobility option and returns the status value > set to [MCOA MALFORMED]. If the Length value is 12, an IPv4 > valid > address MUST be present. Otherwise, an IPv6 address MUST be > stored in the Binding Identifier mobility option. > > The description here is a bit dubious. If the length is 12 or 20, the > next 32 or 128 bits after the Reserved field would be treated as the > care-of address. Since this is a section about CN/HA's operation, it > shouldn't be CoA "MUST be present". This is not a requirement for the > recipient, it is a requirement on the sender. Instead, the CN/HA > "MUST > treat the next few bits after Reserved field as the CoA. Similarly, > there is no such thing as "If the care-of address is not present". > So, > the wording should instead be "if the address in the Care-of Address > is > not valid". Similarly for the later part, it is not a question of > IPv4/IPv6 address must be present. It should instead be phrased as > that > the CN/HA must treat the next 32 bits as an IPv4 care-of address, or > next 128bits as an IPv6 care-of address, and then returns error if > it is > not a valid care-of address. > > --- > > [Section 6.3, pg 29] > > o If the 'O' flag is set in the de-registering Binding Update, it > is > ignored. If the 'H' flag is set, the home agent stores a home > address in the Care-of Address field of the binding cache entry. > The home agent also stops performing proxy ND for the mobile > node's home address. > > The last part doesn't seems to be in sync with what was mentioned in > Section 5.6.3. I think the home agent would decide whether to stop or > continue ND proxy depending on whether it is the only router on the > home > link, and responds with the appropriate Status code according to Sect > 5.6.3. right. will fix this. > > > --- > > [Section 6.3, pg 29] > > When a correspondent node sends a Binding Acknowledgement, the > status > value MUST be always stored in the Status field of the Binding > Acknowledgement and the Status field of Binding Identifier mobility > option set to zero. For the home agent, the status value can be > stored in the Status field of either a Binding Acknowledgement or a > Binding Identifier mobility option. If the status value is specific > to one of bindings in the bulk registration, the status value MUST > be > stored in the Status field in the corresponding Binding Identifier > mobility option. In this case, [MCOA NOTCOMPLETE] MUST be set to > the > Status field of the Binding Acknowledgement so that the receiver can > examine the Status field of each Binding Identifier mobility option > for further operations. > > In the later part on home agent of the above paragraph, I think it > might > be necessary to say that for BID Options that do not have a specific > different status, the status field of these BID options should be > set to > zero (which mean the status in the BA will be used). OK. > > > --- > > [Section 6.4, Pg 30] > > 6.4. Sending Binding Refresh Request > > When a node (home agent or correspondent node) sends a Binding > Refresh Request for a particular binding created with the BID, the > node SHOULD include the Binding Identifier mobility option in the > Binding Refresh Request. If the mobile node had used bulk > registration, the sender SHOULD include all the Binding Identifier > mobility options. If the mobile node had not used bulk > registration, > the sender includes the Binding Identifier mobility options only for > those bindings that need to be refreshed. > > The second sentence seems to indicate that the home agent must somehow > recall if the mobile node had previously used Bulk Registration or > not. > No where else in this spec seems to mention this requirement for the > home agent. My personal feeling is that it is redundant, since if the > mobile node used bulk registration, the lifetime for all the CoA > should > be the same, and they would have to be refreshed at the same time and > hence be included in the BRR anyway. So I suggest removing the 2nd > sentence, and remove the first part of the 3rd sentence -- i.e.: > > When a node (home agent or correspondent node) sends a Binding > Refresh Request for a particular binding created with the BID, the > node SHOULD include the Binding Identifier mobility option in the > Binding Refresh Request. The sender MAY include multiple Binding > Identifier mobility options if there are multiple bindings that > need to be refreshed. OK, I will use your proposed text. > > > --- > > [Section 6.5, pg 30-31] > > Editorial: Remove "silently" in > > ..... If no > binding is found, the packets MUST be silently discarded. The node > MUST also send a Binding Error message as specified in [RFC-3775]. > > If a BE is sent, it is not a "silently discard". > > --- > > I am deferring Sect 8 and Sect 9 for later as I need to read the other > drafts more carefully first to understand the interactions. > > I am, however, curious with the omission of HMIP from this spec. You > have Section 7 on NEMO, Section 8 on DSMIP (which is a work-in- > progress, > so arguably the interaction might change if there are some changes in > DSMIP), but nothing is said on HMIP which is already an RFC long ago. There were strong interests to extend NEMO/DSMIP for MCoA. You are the first to mention HMIP. Are you interested in HMIP? How about considering HMIP after PS RFC is published, if anybody are interested in this work. I am not going to support HMIP in this spec and want to finish WGLC. thanks! ryuji > > > /rgds > /cwng > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon May 26 23:15:07 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B214A3A6C17; Mon, 26 May 2008 23:15:07 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDDA43A6BDC for ; Mon, 26 May 2008 23:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJwTTIhWfvxg for ; Mon, 26 May 2008 23:15:04 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 181243A6C16 for ; Mon, 26 May 2008 23:15:03 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id m4R6F2jD013180; Tue, 27 May 2008 15:15:02 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb2) with ESMTP id m4R6F2k22768; Tue, 27 May 2008 15:15:02 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili04) with ESMTP id m4R6F2K25920; Tue, 27 May 2008 15:15:02 +0900 (JST) Received: from bach.sg.panasonic.com ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 May 2008 14:14:01 +0800 Received: by bach.sg.panasonic.com (Postfix, from userid 1000) id 87E71D4085; Tue, 27 May 2008 14:29:14 +0800 (SGT) From: Chan-Wah Ng To: Ryuji Wakikawa In-Reply-To: References: <20080430013001.6B3FA3A6C64@core3.amsl.com> <481858A0.20102@it.uc3m.es> <1209786547.6310.17.camel@localhost> Date: Tue, 27 May 2008 14:29:13 +0800 Message-Id: <1211869754.6561.106.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 X-OriginalArrivalTime: 27 May 2008 06:14:01.0876 (UTC) FILETIME=[DB968540:01C8BFC0] Cc: mext Subject: Re: [MEXT] WGLC for draft-ietf-monami6-multiplecoa-07.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Ryuji, Some responses to your responses inline (while others are snipped). On Tue, 2008-05-27 at 13:51 +0900, Ryuji Wakikawa wrote: > Hello Chan-Wah > > Thanks for detailed comments. > > All your comments are editorial and clarification. > We can easily fix your comments. > Thanks again. Some comments are below. > > On 2008/05/03, at 12:49, Chan-Wah Ng wrote: > > Bulk Registration > > > > A mobile node can register multiple bindings at once by sending a > > single Binding Update. A mobile node can also replace some or > > all > > the bindings available at the home agent with the new bindings by > > using the bulk registration. Bulk registration is supported only > > for home registration (i.e. with the home agent) as explained in > > Section 5.4. A mobile node MUST NOT perform bulk registration > > with a correspondent node. > > > > The last part seems to be too strong ... the only reason why an MN > > should not perform bulk registration IMHO is because this > > specification > > does not want to support it "for protocol simplicity". Simply say so > > like changing the last sentence to "Bulk registration with a > > correpondent node is not supported in this specification." Saying MN > > "MUST NOT" seems to suggest there is a strong security or protocol > > design reason for MN not to do so which is not explained -- the only > > reason stated is in pg 7: > > This specification isn't designed to perform bulk registration to CN. > We need to prohibit this, right? > Prohibit? Why? I think it suffice to say this spec does not provide mechanism for bulk registration to CN. > > .... For protocol > > simplicity, bulk registration to correspondent nodes is not > > supported > > in this document. This is because the Return Routability mechanism > > introduced in [RFC-3775] cannot be easily extended to verify > > multiple > > care-of addresses stored in a single Binding Update. > > > > This, IMHO, does not justify the use of a strong "MUST NOT". > > Here are the definition from RFC2119. > > 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the > definition is an absolute prohibition of the specification. > 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that > there may exist valid reasons in particular circumstances when the > particular behavior is acceptable or even useful, but the full > implications should be understood and the case carefully weighed > before implementing any behavior described with this label. > > I still think "MUST NOT" is appropriate here. > Bulk registration specified in this doc has no mechanism to verify the > CoAs. RR cannot not protect all the CoAs. > Other separate document can specify the bulk registration for CN later. > If you still prefer to use the phrase "MUST NOT", I suggest some text change: ... home registration (i.e. with the home agent) as explained in Section 5.4. A mobile node MUST NOT use the bulk registration mechanism described in this specification with a correspondent node. > > > > [ Section 4.2 - Pg 12-14] > > > > 4.2. Binding Identifier Mobility Option > > > > Typically for new options defined, the byte alignment should be > > specified. This may get a bit tricky, though, since depending on > > whether Care-of Address field is present or not, and what kind of > > care-of address, the byte alignment requirement will change. > > > > ... > > > > Status > > > > When the Binding Identifier mobility option is included in a > > Binding Acknowledgement, this field overwrites the status field > > in > > the Binding Acknowledgement. If this field is zero, the receiver > > MUST use the registration status stored in the Binding > > Acknowledgement message. This Status field is also used to carry > > error information related to the care-of address test in the > > Care-of Test message. The status is 8-bit unsigned integer. The > > possible status codes are the same as the status codes of Binding > > Acknowledgement. > > > > What happens to this field when the option is included in the Binding > > Update message? Should it be set to zero, and ignored by the receiver > > or what? > > Should be set to zero. However, the receiver ignores this field if the > option is carried with BU. > My point is, this receiver behavior should be specified. > > > > > > ... > > > > Reserved > > > > 5 bits Reserved field. The reserved field MUST be zero. > > > > Typically, a spec would mandate sender to set reserved bit to 0 and > > response of receiver if the bits are non-zero -- so should the > > receiver > > silently ignore the bits, silently discard the BU, reply with Binding > > Error, or what? > > There is no reason to reject the BU only because the reserved field is > not zero. > As above, my point is, this behavior should be specified. > > I am, however, curious with the omission of HMIP from this spec. You > > have Section 7 on NEMO, Section 8 on DSMIP (which is a work-in- > > progress, > > so arguably the interaction might change if there are some changes in > > DSMIP), but nothing is said on HMIP which is already an RFC long ago. > > > There were strong interests to extend NEMO/DSMIP for MCoA. > You are the first to mention HMIP. Are you interested in HMIP? > How about considering HMIP after PS RFC is published, if anybody are > interested in this work. > > I am not going to support HMIP in this spec and want to finish WGLC. > Ah, it is not that I want HMIP ... I just see no reason why MCoA cannot be used with HMIP. A simple description (as simple as that for NEMO) would have sufficed, I think. However, I am okay if the WG feels it is okay to omit HMIP. Just be careful then with the flow filtering work -- I think I read some version of the individual drafts, and they claim that it is possible for a MAP to be a filtering agent. I just don't see how MAP can be a filtering agent if it does not have the capability to accept multiple LCoAs bound to a RCoA. /rgds /cwng _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Mon May 26 23:58:17 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD34028C20D; Mon, 26 May 2008 23:58:17 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC39828C20F for ; Mon, 26 May 2008 23:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyXKrPrp5lMS for ; Mon, 26 May 2008 23:58:15 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by core3.amsl.com (Postfix) with ESMTP id CC63928C205 for ; Mon, 26 May 2008 23:58:15 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id k34so2716904wah.25 for ; Mon, 26 May 2008 23:58:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; bh=damPnsWpO1RCDD06fmj/jPTNx12Ifa/WnuOB6MrUEhg=; b=dCQMpOhWwg33Ab8fL9gqjAx3hKXNrVbW9aC12Kf4DWbQ/F8vkV9Y646YFnEXpJDa+eRkjryAXpfGnvenbAbbEqprReFxGQkAZX+zhQuiY93R1GGb7/1j0eysSv1ttDYqjT2sEtwXk3rhYAr9+h0Z1g7O3XV+Fj7J5C1eBEMAgOU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type:content-transfer-encoding:mime-version:date:cc:x-mailer; b=HkkE4btJBNuBk1rO7M6wgQ0sDqxW2iwNspq/9OGAwljv1bPTd8l0TZtUi0J1oSizqnrEkM6XzKGqYFfySozGcJZL/wDyDmdYXUNNOpYw7hwH6/0UUbKs6pOjzTnRyJT3M2bhyB+oIHB0aLqvVXvZT6lW1VNM4QYh/AFe2buC8uo= Received: by 10.114.170.1 with SMTP id s1mr984598wae.133.1211871498336; Mon, 26 May 2008 23:58:18 -0700 (PDT) Received: from EM119-72-41-5.pool.e-mobile.ne.jp ( [119.72.41.5]) by mx.google.com with ESMTPS id j29sm28716230waf.49.2008.05.26.23.58.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 26 May 2008 23:58:17 -0700 (PDT) From: Ryuji Wakikawa To: Chan-Wah Ng In-Reply-To: <1211869754.6561.106.camel@localhost> References: <20080430013001.6B3FA3A6C64@core3.amsl.com> <481858A0.20102@it.uc3m.es> <1209786547.6310.17.camel@localhost> <1211869754.6561.106.camel@localhost> Message-Id: <536D1D30-0918-4A4F-A540-47719F5EC5FD@gmail.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 27 May 2008 15:58:00 +0900 X-Mailer: Apple Mail (2.919.2) Cc: mext Subject: Re: [MEXT] WGLC for draft-ietf-monami6-multiplecoa-07.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Chan-Wah On 2008/05/27, at 15:29, Chan-Wah Ng wrote: > Hello Ryuji, > > Some responses to your responses inline (while others are snipped). > > On Tue, 2008-05-27 at 13:51 +0900, Ryuji Wakikawa wrote: >> Hello Chan-Wah >> >> Thanks for detailed comments. >> >> All your comments are editorial and clarification. >> We can easily fix your comments. >> Thanks again. Some comments are below. >> >> On 2008/05/03, at 12:49, Chan-Wah Ng wrote: >>> Bulk Registration >>> >>> A mobile node can register multiple bindings at once by >>> sending a >>> single Binding Update. A mobile node can also replace some or >>> all >>> the bindings available at the home agent with the new bindings >>> by >>> using the bulk registration. Bulk registration is supported >>> only >>> for home registration (i.e. with the home agent) as explained in >>> Section 5.4. A mobile node MUST NOT perform bulk registration >>> with a correspondent node. >>> >>> The last part seems to be too strong ... the only reason why an MN >>> should not perform bulk registration IMHO is because this >>> specification >>> does not want to support it "for protocol simplicity". Simply say >>> so >>> like changing the last sentence to "Bulk registration with a >>> correpondent node is not supported in this specification." Saying >>> MN >>> "MUST NOT" seems to suggest there is a strong security or protocol >>> design reason for MN not to do so which is not explained -- the only >>> reason stated is in pg 7: >> >> This specification isn't designed to perform bulk registration to CN. >> We need to prohibit this, right? >> > > Prohibit? Why? I think it suffice to say this spec does not provide > mechanism for bulk registration to CN. > > >>> .... For protocol >>> simplicity, bulk registration to correspondent nodes is not >>> supported >>> in this document. This is because the Return Routability mechanism >>> introduced in [RFC-3775] cannot be easily extended to verify >>> multiple >>> care-of addresses stored in a single Binding Update. >>> >>> This, IMHO, does not justify the use of a strong "MUST NOT". >> >> Here are the definition from RFC2119. >> >> 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the >> definition is an absolute prohibition of the specification. >> 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that >> there may exist valid reasons in particular circumstances when the >> particular behavior is acceptable or even useful, but the full >> implications should be understood and the case carefully weighed >> before implementing any behavior described with this label. >> >> I still think "MUST NOT" is appropriate here. >> Bulk registration specified in this doc has no mechanism to verify >> the >> CoAs. RR cannot not protect all the CoAs. >> Other separate document can specify the bulk registration for CN >> later. >> > If you still prefer to use the phrase "MUST NOT", I suggest some text > change: > > ... home registration (i.e. with the home agent) as explained in > Section 5.4. A mobile node MUST NOT use the bulk registration > mechanism described in this specification with a correspondent > node. this is fine. > > >>> >>> [ Section 4.2 - Pg 12-14] >>> >>> 4.2. Binding Identifier Mobility Option >>> >>> Typically for new options defined, the byte alignment should be >>> specified. This may get a bit tricky, though, since depending on >>> whether Care-of Address field is present or not, and what kind of >>> care-of address, the byte alignment requirement will change. >>> >>> ... >>> >>> Status >>> >>> When the Binding Identifier mobility option is included in a >>> Binding Acknowledgement, this field overwrites the status field >>> in >>> the Binding Acknowledgement. If this field is zero, the >>> receiver >>> MUST use the registration status stored in the Binding >>> Acknowledgement message. This Status field is also used to >>> carry >>> error information related to the care-of address test in the >>> Care-of Test message. The status is 8-bit unsigned integer. >>> The >>> possible status codes are the same as the status codes of >>> Binding >>> Acknowledgement. >>> >>> What happens to this field when the option is included in the >>> Binding >>> Update message? Should it be set to zero, and ignored by the >>> receiver >>> or what? >> >> Should be set to zero. However, the receiver ignores this field if >> the >> option is carried with BU. >> > > My point is, this receiver behavior should be specified. I will add this sentence. "The receiver MUST ignore this field if the option is not carried with BA." > > > >>> >>> >>> ... >>> >>> Reserved >>> >>> 5 bits Reserved field. The reserved field MUST be zero. >>> >>> Typically, a spec would mandate sender to set reserved bit to 0 and >>> response of receiver if the bits are non-zero -- so should the >>> receiver >>> silently ignore the bits, silently discard the BU, reply with >>> Binding >>> Error, or what? >> >> There is no reason to reject the BU only because the reserved field >> is >> not zero. >> > > As above, my point is, this behavior should be specified. I'll change it to "The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver." > > >>> I am, however, curious with the omission of HMIP from this spec. >>> You >>> have Section 7 on NEMO, Section 8 on DSMIP (which is a work-in- >>> progress, >>> so arguably the interaction might change if there are some changes >>> in >>> DSMIP), but nothing is said on HMIP which is already an RFC long >>> ago. >> >> >> There were strong interests to extend NEMO/DSMIP for MCoA. >> You are the first to mention HMIP. Are you interested in HMIP? >> How about considering HMIP after PS RFC is published, if anybody are >> interested in this work. >> >> I am not going to support HMIP in this spec and want to finish WGLC. >> > > Ah, it is not that I want HMIP ... I just see no reason why MCoA > cannot > be used with HMIP. A simple description (as simple as that for NEMO) > would have sufficed, I think. However, I am okay if the WG feels it > is > okay to omit HMIP. Just be careful then with the flow filtering > work -- > I think I read some version of the individual drafts, and they claim > that it is possible for a MAP to be a filtering agent. I just don't > see > how MAP can be a filtering agent if it does not have the capability to > accept multiple LCoAs bound to a RCoA. If nobody uses it and wants it, no reason to support HMIP. It is endless if we support all the extensions for Mobile IP;-) ryuji > > > /rgds > /cwng _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From c.suchotinunt@klingerassociates.com Tue May 27 05:20:45 2008 Return-Path: X-Original-To: ietfarch-nemo-archive@core3.amsl.com Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1775C3A69C7; Tue, 27 May 2008 05:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.364 X-Spam-Level: X-Spam-Status: No, score=-5.364 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FS_REPLICA=0.994, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_USERONOCOM=1.444, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_24=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKRKUP+uhobJ; Tue, 27 May 2008 05:20:38 -0700 (PDT) Received: from 84.125.158.166.dyn.user.ono.com (84.125.158.166.dyn.user.ono.com [84.125.158.166]) by core3.amsl.com (Postfix) with SMTP id 074CE28C28D; Tue, 27 May 2008 05:19:52 -0700 (PDT) X-Originating-IP: 124.82.248.196 by smtp.84.125.158.166; Tue, 27 May 2008 08:20:01 -0500 Message-ID: From: "Katelyn Ransom" Reply-To: "Katelyn Ransom" To: multimob@ietf.org Subject: The discreet replica store Date: Tue, 27 May 2008 08:20:01 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Bvlgari watch is an extraordinary masterpiece that is born from the marriage of watch making and jewelry expertise. Only the most discriminating and sophisticated watch users dare put a Bv1gari on their wrists, but once the metal touches their skin, they are bound forever... How would you like to become one of the lucky few that have experienced the pleasure of sporting a Bvlgari timepiece? Now you can, and at a very reduced cost! Prestige Replicas offers a tremendous collection of Bvlgari replicas starting just a little above $200... So now there is no reason why you can't have your very own Bvlgari today! http://www%2Ebybyusse%2Ecom/ From mext-bounces@ietf.org Wed May 28 02:09:43 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A47C03A6945; Wed, 28 May 2008 02:09:40 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 719E528C14D for ; Wed, 28 May 2008 02:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwdRwuW9Bd47 for ; Wed, 28 May 2008 02:09:13 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 39DB028C13F for ; Wed, 28 May 2008 02:09:11 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id m4S99HYK007592; Wed, 28 May 2008 18:09:17 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb1) with ESMTP id m4S99Hu02953; Wed, 28 May 2008 18:09:17 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili04) with ESMTP id m4S99IK12987; Wed, 28 May 2008 18:09:18 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.116]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 May 2008 17:08:17 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Wed, 28 May 2008 17:07:58 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Wed, 28 May 2008 17:07:58 +0800 From: "Benjamin Lim" To: "'Ahmad Muhanna'" References: <000601c8b7f1$77b54970$6510ef0a@psl.local> <007a01c8bbb2$ee3bfa20$7471510a@psl.local> Date: Wed, 28 May 2008 17:07:58 +0800 Message-ID: <007701c8c0a2$528a4f10$7471510a@psl.local> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 thread-index: AciuWf2Y1JeerkUGQ46fWXJo4+sPHAJi0ddQAAHn2VAAAAgmQAAAcU1AAAA/eVAAAC0dUAAAOEgAAJ93hdAAT+2v8AAXAjuwASXCOgA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: X-OriginalArrivalTime: 28 May 2008 09:08:17.0138 (UTC) FILETIME=[5DD2A520:01C8C0A2] Cc: mext@ietf.org Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-01.txt (Resend) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad, Ok. I will await the next revision then. Base on my review, I feel that this draft should be ready for WG call. I leave it up to the chairs and WG to decide. Regards, Benjamin Lim > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > Sent: Thursday, May 22, 2008 9:00 PM > To: Benjamin Lim > Cc: mext@ietf.org > Subject: RE: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-01.txt (Resend) > > Hi Ben, > > The text looks good. In the next revision, "hopefully as a wg > document" > I will make sure that the intent of the text is captured. > > Again, Many thanks for your review. > > > Regards, > Ahmad > > > > -----Original Message----- > > From: Benjamin Lim [mailto:benjamin.limck@sg.panasonic.com] > > Sent: Wednesday, May 21, 2008 9:24 PM > > To: Muhanna, Ahmad (RICH1:2H10) > > Cc: mext@ietf.org > > Subject: RE: [MEXT] FW: I-D > > Action:draft-muhanna-mext-binding-revocation-01.txt (Resend) > > > > Hi Ahmad, > > > > Reply to one of your comment. I snip out the part. > > > > =8==8<=8== > > > > [Ben] Is there such a thing as a wildcard NAI? Why can't > > > the LMA just > > > > include every single affect MN-ID as an option in the BRI? > > > [Ahmad] > > > > > > What I meant by wildcard NAI is something like "*@abcxyz.com". I > > > believe allowing this is useful. If the LMA would like to > > revoke all > > > mobile nodes by including multiple MN-IDs, I believe that > > is allowed, > > > if the text is not clear, we will fix it. > > [Ben] Ok I get your idea. Meaning a NAI that represent a > group of MNs > > belong to a particular domain. I suggest the following wording then. > > > > ... > > > > 8.1.1. Sending Binding Revocation Indication > > > > ... > > > > > > In this case, the local mobility anchor MUST include a > mobility option > > to identify the impacted bindings, e.g. > > MN-ID option with a wildcard NAI, e.g. > > *@companyabc.com, to identify all the mobile nodes BCEs > that need to > > be removed. > > > > > > > > In this case, the local mobility anchor MUST include a > mobility option > > to identify the impacted bindings. For example, if the > local mobility > > anchor wants to revoke the bindings of all mobile nodes from a > > particular domain (companyabc.com), the local mobility anchor would > > include multiple MN-ID options to reflect the NAI of the > affect mobile > > nodes. Another way for the local mobility anchor to revoke all > > bindings from companyabc.com would be to use a special NAI that > > represent mobile nodes from this domain. For this, the > local mobility > > anchor would only include a single MN-ID option containing this > > special NAI to identify all the mobile nodes BCEs that need to be > > removed. > > > > How does this sound? > > > > Regards, > > Benjamin Lim > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed May 28 05:58:30 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 869C43A6A52; Wed, 28 May 2008 05:58:30 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 800E23A69EF for ; Wed, 28 May 2008 05:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJmOwKZEMkpN for ; Wed, 28 May 2008 05:58:24 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id B81193A6832 for ; Wed, 28 May 2008 05:58:23 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m4SCwRd22269; Wed, 28 May 2008 12:58:28 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 May 2008 07:58:25 -0500 Message-ID: In-Reply-To: <007701c8c0a2$528a4f10$7471510a@psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-01.txt (Resend) Thread-Index: AciuWf2Y1JeerkUGQ46fWXJo4+sPHAJi0ddQAAHn2VAAAAgmQAAAcU1AAAA/eVAAAC0dUAAAOEgAAJ93hdAAT+2v8AAXAjuwASXCOgAACBFD4A== References: <000601c8b7f1$77b54970$6510ef0a@psl.local> <007a01c8bbb2$ee3bfa20$7471510a@psl.local> <007701c8c0a2$528a4f10$7471510a@psl.local> From: "Ahmad Muhanna" To: "Benjamin Lim" Cc: mext@ietf.org Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-01.txt (Resend) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Thanks Ben! Will make sure the proposed changes is captured in the new revision. On adopting this draft as a wg doc; Yes, we are waiting for the chairs guidance on the next step. Thanks again. Regards, Ahmad > -----Original Message----- > From: Benjamin Lim [mailto:benjamin.limck@sg.panasonic.com] > Sent: Wednesday, May 28, 2008 4:08 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: mext@ietf.org > Subject: RE: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-01.txt (Resend) > > Hi Ahmad, > > Ok. I will await the next revision then. Base on my review, I > feel that this draft should be ready for WG call. I leave it > up to the chairs and WG to decide. > > Regards, > Benjamin Lim > > > -----Original Message----- > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > Sent: Thursday, May 22, 2008 9:00 PM > > To: Benjamin Lim > > Cc: mext@ietf.org > > Subject: RE: [MEXT] FW: I-D > > Action:draft-muhanna-mext-binding-revocation-01.txt (Resend) > > > > Hi Ben, > > > > The text looks good. In the next revision, "hopefully as a wg > > document" > > I will make sure that the intent of the text is captured. > > > > Again, Many thanks for your review. > > > > > > Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: Benjamin Lim [mailto:benjamin.limck@sg.panasonic.com] > > > Sent: Wednesday, May 21, 2008 9:24 PM > > > To: Muhanna, Ahmad (RICH1:2H10) > > > Cc: mext@ietf.org > > > Subject: RE: [MEXT] FW: I-D > > > Action:draft-muhanna-mext-binding-revocation-01.txt (Resend) > > > > > > Hi Ahmad, > > > > > > Reply to one of your comment. I snip out the part. > > > > > > =8==8<=8== > > > > > [Ben] Is there such a thing as a wildcard NAI? Why can't > > > > the LMA just > > > > > include every single affect MN-ID as an option in the BRI? > > > > [Ahmad] > > > > > > > > What I meant by wildcard NAI is something like > "*@abcxyz.com". I > > > > believe allowing this is useful. If the LMA would like to > > > revoke all > > > > mobile nodes by including multiple MN-IDs, I believe that > > > is allowed, > > > > if the text is not clear, we will fix it. > > > [Ben] Ok I get your idea. Meaning a NAI that represent a > > group of MNs > > > belong to a particular domain. I suggest the following > wording then. > > > > > > ... > > > > > > 8.1.1. Sending Binding Revocation Indication > > > > > > ... > > > > > > > > > In this case, the local mobility anchor MUST include a > > mobility option > > > to identify the impacted bindings, e.g. > > > MN-ID option with a wildcard NAI, e.g. > > > *@companyabc.com, to identify all the mobile nodes BCEs > > that need to > > > be removed. > > > > > > > > > > > > In this case, the local mobility anchor MUST include a > > mobility option > > > to identify the impacted bindings. For example, if the > > local mobility > > > anchor wants to revoke the bindings of all mobile nodes from a > > > particular domain (companyabc.com), the local mobility > anchor would > > > include multiple MN-ID options to reflect the NAI of the > > affect mobile > > > nodes. Another way for the local mobility anchor to revoke all > > > bindings from companyabc.com would be to use a special NAI that > > > represent mobile nodes from this domain. For this, the > > local mobility > > > anchor would only include a single MN-ID option containing this > > > special NAI to identify all the mobile nodes BCEs that need to be > > > removed. > > > > > > How does this sound? > > > > > > Regards, > > > Benjamin Lim > > > > > > > > > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed May 28 06:12:53 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 159B13A6C4F; Wed, 28 May 2008 06:12:53 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 571D93A6AAE for ; Wed, 28 May 2008 06:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=1.743, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWGbHiM+OlGm for ; Wed, 28 May 2008 06:12:46 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id DABEE3A69EA for ; Wed, 28 May 2008 06:12:45 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [163.117.203.43])by smtp02.uc3m.es (Postfix) with ESMTP id 8D42139DD0F; Wed, 28 May 2008 15:12:50 +0200 (CEST) Message-ID: <483D5A50.1000208@it.uc3m.es> Date: Wed, 28 May 2008 15:12:48 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: mext@ietf.org X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-21.0335 TC:1F TRN:52 TV:5.5.1026(15936.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Julien Laganier Subject: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi all, In our new charter we have a new item on a generic notification mechanism. During discussion over the last weeks, it seems to me that the WG needs to make a decision about what is the scope of the generic notification In summary, we need to decide which is the scope of the generic notification and what is the scope of the existing MH types. Essentially, what need to be as clear as possible are the criteria for using the generic notification and which is the criteria for using a MH type. We would kindly ask the WG to comment on this, so we can make a decision Next, i include some background information about how i see this, but feel free to completely ignore it. I guess that one way to scope the generic notification, we could first define what is the goal of the generic notification. From Sri's draft, for instance, my understanding is that the generic notification goal is to allow a mean to provide asynchronous messages. (i am not sure what asynchronous means in this context, but i assume that it means not included in a BU/BA exchange??). If that is the case, i don't see why we need this, since we can always use another mobility header and define new messages to be exchanged. From Vijay's email, i understand that one of the goals is to save MH types, since they are a scarce resource. That seems reasonable. Raj mentioned that Generic notification is to be used for non critical things. Other mentioned that this should only be used for send and discard things. Now, the next question then is when to use a new MH header and when to use the generic notification. I think the generic notification document needs to explicitly define its scope. I guess that the elements that should be taken into account for the definition of the scope are the message exchange supported by the generic notification, the security mode, others?. In the message exchange, the question is whether the generic notification is just a notification, a notification plus an ACK, reliable delivery (i.e. retransmission till the sender receives an ACK), or a more complex message exchange i.e. more than one message retransmitted in each direction. Now, one option would be to define the generic notification so broad that it is a mere extension of the MH type, so that we can encode more values in there, without much definition of the message format. Another option would be to define a query/response message format and scope the generic notification to this type of simple interactions. A third option would be to define a reliable delivery, whith tiemouts and retransmissions (slightly more complex than the previous one) Other options that support more complex message exchange could also be conceived. So, bottom line we need to clearly define the scope of the generic notification and when to use MH types for extnesions. This include the type of message exchange supported, the type of information conveyed (critical or just infoormation), security and so on. I think this is a high level disucssion that the WG needs to have before we can move forward with the generic notification and also with the binding revocation, since once we define what is the scope of generic notification and the MH type usage, we will be able to conclude in which category the binding revocation falls. Regards, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed May 28 07:19:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 582693A69A5; Wed, 28 May 2008 07:19:04 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 325623A69A5 for ; Wed, 28 May 2008 07:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWxT+wMOsTAw for ; Wed, 28 May 2008 07:19:02 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 2A6E53A698B for ; Wed, 28 May 2008 07:19:02 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K1L00DSX13X9Q@usaga04-in.huawei.com> for mext@ietf.org; Wed, 28 May 2008 09:19:10 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K1L00IO813VT2@usaga04-in.huawei.com> for mext@ietf.org; Wed, 28 May 2008 09:19:09 -0500 (CDT) Date: Wed, 28 May 2008 09:19:07 -0500 From: Frank Xia To: Ahmad Muhanna Message-id: <004d01c8c0cd$cab94fb0$5c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <000601c8b7f1$77b54970$6510ef0a@psl.local> <007a01c8bbb2$ee3bfa20$7471510a@psl.local> <007701c8c0a2$528a4f10$7471510a@psl.local> Cc: mext@ietf.org Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-01.txt (Resend) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad I think the draft is good enough to advance. Just one question, is the draft applicable to WiMAX(or 3GPP2) in which IPsec is not mandatory? BR Frank ----- Original Message ----- From: "Ahmad Muhanna" To: "Benjamin Lim" Cc: Sent: Wednesday, May 28, 2008 7:58 AM Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-01.txt (Resend) > Thanks Ben! > Will make sure the proposed changes is captured in the new revision. > > On adopting this draft as a wg doc; Yes, we are waiting for the chairs > guidance on the next step. > > Thanks again. > > Regards, > Ahmad > > >> -----Original Message----- >> From: Benjamin Lim [mailto:benjamin.limck@sg.panasonic.com] >> Sent: Wednesday, May 28, 2008 4:08 AM >> To: Muhanna, Ahmad (RICH1:2H10) >> Cc: mext@ietf.org >> Subject: RE: [MEXT] FW: I-D >> Action:draft-muhanna-mext-binding-revocation-01.txt (Resend) >> >> Hi Ahmad, >> >> Ok. I will await the next revision then. Base on my review, I >> feel that this draft should be ready for WG call. I leave it >> up to the chairs and WG to decide. >> >> Regards, >> Benjamin Lim >> >> > -----Original Message----- >> > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] >> > Sent: Thursday, May 22, 2008 9:00 PM >> > To: Benjamin Lim >> > Cc: mext@ietf.org >> > Subject: RE: [MEXT] FW: I-D >> > Action:draft-muhanna-mext-binding-revocation-01.txt (Resend) >> > >> > Hi Ben, >> > >> > The text looks good. In the next revision, "hopefully as a wg >> > document" >> > I will make sure that the intent of the text is captured. >> > >> > Again, Many thanks for your review. >> > >> > >> > Regards, >> > Ahmad >> > >> > >> > > -----Original Message----- >> > > From: Benjamin Lim [mailto:benjamin.limck@sg.panasonic.com] >> > > Sent: Wednesday, May 21, 2008 9:24 PM >> > > To: Muhanna, Ahmad (RICH1:2H10) >> > > Cc: mext@ietf.org >> > > Subject: RE: [MEXT] FW: I-D >> > > Action:draft-muhanna-mext-binding-revocation-01.txt (Resend) >> > > >> > > Hi Ahmad, >> > > >> > > Reply to one of your comment. I snip out the part. >> > > >> > > =8==8<=8== >> > > > > [Ben] Is there such a thing as a wildcard NAI? Why can't >> > > > the LMA just >> > > > > include every single affect MN-ID as an option in the BRI? >> > > > [Ahmad] >> > > > >> > > > What I meant by wildcard NAI is something like >> "*@abcxyz.com". I >> > > > believe allowing this is useful. If the LMA would like to >> > > revoke all >> > > > mobile nodes by including multiple MN-IDs, I believe that >> > > is allowed, >> > > > if the text is not clear, we will fix it. >> > > [Ben] Ok I get your idea. Meaning a NAI that represent a >> > group of MNs >> > > belong to a particular domain. I suggest the following >> wording then. >> > > >> > > ... >> > > >> > > 8.1.1. Sending Binding Revocation Indication >> > > >> > > ... >> > > >> > > >> > > In this case, the local mobility anchor MUST include a >> > mobility option >> > > to identify the impacted bindings, e.g. >> > > MN-ID option with a wildcard NAI, e.g. >> > > *@companyabc.com, to identify all the mobile nodes BCEs >> > that need to >> > > be removed. >> > > >> > > >> > > >> > > In this case, the local mobility anchor MUST include a >> > mobility option >> > > to identify the impacted bindings. For example, if the >> > local mobility >> > > anchor wants to revoke the bindings of all mobile nodes from a >> > > particular domain (companyabc.com), the local mobility >> anchor would >> > > include multiple MN-ID options to reflect the NAI of the >> > affect mobile >> > > nodes. Another way for the local mobility anchor to revoke all >> > > bindings from companyabc.com would be to use a special NAI that >> > > represent mobile nodes from this domain. For this, the >> > local mobility >> > > anchor would only include a single MN-ID option containing this >> > > special NAI to identify all the mobile nodes BCEs that need to be >> > > removed. >> > > >> > > How does this sound? >> > > >> > > Regards, >> > > Benjamin Lim >> > > >> > > >> > > >> > >> >> >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed May 28 07:33:55 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88A783A69A5; Wed, 28 May 2008 07:33:55 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0F533A69A5 for ; Wed, 28 May 2008 07:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.067 X-Spam-Level: X-Spam-Status: No, score=-6.067 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omU-ruWfw8p1 for ; Wed, 28 May 2008 07:33:52 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 9400E3A6808 for ; Wed, 28 May 2008 07:33:52 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m4SEXvc29536; Wed, 28 May 2008 14:33:57 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 May 2008 09:33:56 -0500 Message-ID: In-Reply-To: <004d01c8c0cd$cab94fb0$5c0c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-01.txt (Resend) Thread-Index: AcjAzc8ziyo3WA0jQBiTqv4gQAS9kgAARhtg References: <000601c8b7f1$77b54970$6510ef0a@psl.local> <007a01c8bbb2$ee3bfa20$7471510a@psl.local> <007701c8c0a2$528a4f10$7471510a@psl.local> <004d01c8c0cd$cab94fb0$5c0c7c0a@china.huawei.com> From: "Ahmad Muhanna" To: "Frank Xia" Cc: mext@ietf.org Subject: Re: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-01.txt (Resend) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Frank, Yes. It is applicable. The intent of the draft is that BRI and BRA are secured using the same security association that was used for protecting the BU/BA. If it is not clear, we will make sure that it is captured. Regards, Ahmad > -----Original Message----- > From: Frank Xia [mailto:xiayangsong@huawei.com] > Sent: Wednesday, May 28, 2008 9:19 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: mext@ietf.org > Subject: Re: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-01.txt (Resend) > > Hi Ahmad > > I think the draft is good enough to advance. > > Just one question, is the draft applicable to WiMAX(or > 3GPP2) in which IPsec is not mandatory? > > BR > Frank > > > ----- Original Message ----- > From: "Ahmad Muhanna" > To: "Benjamin Lim" > Cc: > Sent: Wednesday, May 28, 2008 7:58 AM > Subject: Re: [MEXT] FW: I-D > Action:draft-muhanna-mext-binding-revocation-01.txt (Resend) > > > > Thanks Ben! > > Will make sure the proposed changes is captured in the new revision. > > > > On adopting this draft as a wg doc; Yes, we are waiting for > the chairs > > guidance on the next step. > > > > Thanks again. > > > > Regards, > > Ahmad > > > > > >> -----Original Message----- > >> From: Benjamin Lim [mailto:benjamin.limck@sg.panasonic.com] > >> Sent: Wednesday, May 28, 2008 4:08 AM > >> To: Muhanna, Ahmad (RICH1:2H10) > >> Cc: mext@ietf.org > >> Subject: RE: [MEXT] FW: I-D > >> Action:draft-muhanna-mext-binding-revocation-01.txt (Resend) > >> > >> Hi Ahmad, > >> > >> Ok. I will await the next revision then. Base on my review, I feel > >> that this draft should be ready for WG call. I leave it up to the > >> chairs and WG to decide. > >> > >> Regards, > >> Benjamin Lim > >> > >> > -----Original Message----- > >> > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > >> > Sent: Thursday, May 22, 2008 9:00 PM > >> > To: Benjamin Lim > >> > Cc: mext@ietf.org > >> > Subject: RE: [MEXT] FW: I-D > >> > Action:draft-muhanna-mext-binding-revocation-01.txt (Resend) > >> > > >> > Hi Ben, > >> > > >> > The text looks good. In the next revision, "hopefully as a wg > >> > document" > >> > I will make sure that the intent of the text is captured. > >> > > >> > Again, Many thanks for your review. > >> > > >> > > >> > Regards, > >> > Ahmad > >> > > >> > > >> > > -----Original Message----- > >> > > From: Benjamin Lim [mailto:benjamin.limck@sg.panasonic.com] > >> > > Sent: Wednesday, May 21, 2008 9:24 PM > >> > > To: Muhanna, Ahmad (RICH1:2H10) > >> > > Cc: mext@ietf.org > >> > > Subject: RE: [MEXT] FW: I-D > >> > > Action:draft-muhanna-mext-binding-revocation-01.txt (Resend) > >> > > > >> > > Hi Ahmad, > >> > > > >> > > Reply to one of your comment. I snip out the part. > >> > > > >> > > =8==8<=8== > >> > > > > [Ben] Is there such a thing as a wildcard NAI? Why can't > >> > > > the LMA just > >> > > > > include every single affect MN-ID as an option in the BRI? > >> > > > [Ahmad] > >> > > > > >> > > > What I meant by wildcard NAI is something like > >> "*@abcxyz.com". I > >> > > > believe allowing this is useful. If the LMA would like to > >> > > revoke all > >> > > > mobile nodes by including multiple MN-IDs, I believe that > >> > > is allowed, > >> > > > if the text is not clear, we will fix it. > >> > > [Ben] Ok I get your idea. Meaning a NAI that represent a > >> > group of MNs > >> > > belong to a particular domain. I suggest the following > >> wording then. > >> > > > >> > > ... > >> > > > >> > > 8.1.1. Sending Binding Revocation Indication > >> > > > >> > > ... > >> > > > >> > > > >> > > In this case, the local mobility anchor MUST include a > >> > mobility option > >> > > to identify the impacted bindings, e.g. > >> > > MN-ID option with a wildcard NAI, e.g. > >> > > *@companyabc.com, to identify all the mobile nodes BCEs > >> > that need to > >> > > be removed. > >> > > > >> > > > >> > > > >> > > In this case, the local mobility anchor MUST include a > >> > mobility option > >> > > to identify the impacted bindings. For example, if the > >> > local mobility > >> > > anchor wants to revoke the bindings of all mobile nodes from a > >> > > particular domain (companyabc.com), the local mobility > >> anchor would > >> > > include multiple MN-ID options to reflect the NAI of the > >> > affect mobile > >> > > nodes. Another way for the local mobility anchor to revoke all > >> > > bindings from companyabc.com would be to use a special > NAI that > >> > > represent mobile nodes from this domain. For this, the > >> > local mobility > >> > > anchor would only include a single MN-ID option > containing this > >> > > special NAI to identify all the mobile nodes BCEs that > need to be > >> > > removed. > >> > > > >> > > How does this sound? > >> > > > >> > > Regards, > >> > > Benjamin Lim > >> > > > >> > > > >> > > > >> > > >> > >> > >> > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed May 28 09:27:02 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24F7E3A6AD0; Wed, 28 May 2008 09:27:02 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A71C3A6AD0 for ; Wed, 28 May 2008 09:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.884 X-Spam-Level: X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ckS-QDCfDkR for ; Wed, 28 May 2008 09:26:59 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id C66903A6AC3 for ; Wed, 28 May 2008 09:26:59 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K1L00HLX717LG@usaga04-in.huawei.com> for mext@ietf.org; Wed, 28 May 2008 11:27:08 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K1L00KTD7168X@usaga04-in.huawei.com> for mext@ietf.org; Wed, 28 May 2008 11:27:07 -0500 (CDT) Date: Wed, 28 May 2008 11:27:05 -0500 From: Frank Xia To: heejin.jang@samsung.com, mext@ietf.org Message-id: <017801c8c0df$aba16420$5c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <23113373.254601211510455515.JavaMail.weblogic@epml10> Subject: [MEXT] Rechartering item proposal X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Folks I propose that DHCPv4 for DSMIP6 home network information as a WG rechartering item. Here are some reasons: 1)DSMIP6 is adopted by 3GPP, and it is necessary to provide protocol support 2)Current "DHCP Option for Home Information Discovery in MIPv6" document only deals with DHCPv6 option and procedure. However, there are many difference between DHCPv4 and DHCPv6. The option defined in the document can't be used in DHCPv4 scenario directly, and DHCPv4 has no dedicated information request message. BR Frank ----- Original Message ----- From: "Heejin Jang" To: "Heejin Jang" ; "Frank Xia" ; Sent: Thursday, May 22, 2008 9:40 PM Subject: Fwd: Re: Re: [MEXT] hiopt (Revised text) > Oh, I misunderstood your question. > > DHCPv4 issue has been proposed and discussed in last month, too > but AD mentioned that we put the dhcpv4 side out for the moment at that > time. > > The hiopt draft aims at supporting IPv4/IPv6 HoA in the IPv6 networks(with > DHCPv6). > IMO, I don't think it is a good idea to handle DHCPv4 and DHCPv6 cases in > a single document > because the specific DHCPv4 messages & procedures are different from those > of DHCPv6 > though the concept is similar. > > Thanks for your concerns. > > - Regards, > Heejin. > > ------- Original Message ------- > Sender : Heejin Jang R&D Staff > Member/Communication & Networking Lab/Samsung Advanced Institute of > Technology > Date : 2008-05-23 10:51 (GMT+09:00) > Title : Re: Re: [MEXT] hiopt (Revised text) > > Hi, Frank. > > That issue was discussed in March and April, but AD (Jari) recommends > that > the draft cover discovery of Mobile IPv6 home agents that have an IPv4 > address, > but NOT Mobile IPv4. > > Thanks for your consideration. :) > > -Best regards, > Heejin > > ------- Original Message ------- > Sender : Frank Xia > Date : 2008-05-23 00:03 (GMT+09:00) > Title : Re: [MEXT] hiopt (Revised text) > > Hi Heejin > > In this draft, a MN uses DHCPv6 to acquire home network information. > > However, if MN only has IPv4 CoA in DSMIPv6 scenario, IMO, > DHCPv4 support is needed. > > What is your opinion? > > BR > Frank ----- Original Message ----- From: Heejin Jang To: Jari Arkko > Cc: Alexandru Petrescu ; mext@ietf.org > Sent: Thursday, May 22, 2008 9:32 AM > Subject: Re: [MEXT] hiopt (Revised text) > Hi, Jari and Vijay. > > I revised the draft as Jari's two comments. > Kindly see the below and give me your feedbacks. > > Thanks for your kind cooperation. :) > > * Modified points > > 1) The 3rd paragragh was modifed according to the Jari's 1st > comment. > 2) For the 2nd comments, we allowed the Sub-opt-code 1 and mandated it > in > a MIP6 Relay option. > > > 1> In Section 3.3 (Common Sub-options), page 9, > > Old: > > While the Sub-opt-code 1 is only available in both the requesting and > the returned Home Network Information options, Sub-opt-codes 2, 3, 4, > and 5 are available only in the returned Home Network Information > option and the MIP6 Relay Agent option. > > New: > > While the Sub-opt-codes 1, 2, 3, 4, and 5 are available in the MIP6 > Relay Agent option and the Home Network Information option returned > by the DHCP server, a value of 1 is the only Sub-opt-code available > in the requesting Home Network Information option by the mobile node. > > 2> In Section 4.2 (NAS/DHCP Relay Agent Behavior), page 13, 2nd > paragraph, > > Old: > > The relay SHOULD include each home network > parameter in a sub-option, and include all sub-options in a single > MIP6 Relay Agent option. It MUST NOT include any sub-option whose > Sub-opt-code is other than 2, 3, 4, and 5 as described in Section > 3.3. > > New: > > (added paragraph) > When providing the home network information, the > relay MUST include a sub-option whose Sub-opt-code is 1, and set the > Home Network Parameter field to the FQDN of the network where the > home information is assigned. That FQDN information will be compared > with the target MSP requested by the mobile node when a DHCP server > searches for the matching information. > > The relay SHOULD include each home network parameter in a sub-option, > and include all sub-options in a single MIP6 Relay Agent option. It > MUST NOT include any sub-option whose Sub-opt-code is other than 1, > 2, 3, 4, and 5 as described in Section 3.3. > > 3> In Section 4.3 (DHCP Server Behavior), page 13, > > Old: > > The home network information > received from the relay SHOULD be kept in the server so that the > server can provide the information when it is requested by the mobile > node. > > The server MUST ignore any sub-option in a MIP6 Relay Agent option > whose Sub-opt-code is other than 2, 3, 4, and 5, as described in > Section 3.3. > > New: > > The MIP6 Relay Agent option which > does not include a sub-option with Sub-opt-code 1 MUST be ignored. > Otherwise, the home network information received from the relay > SHOULD be kept in the server so that the server can provide the > information when it is requested by the mobile node. > > The server MUST ignore any sub-option in a MIP6 Relay Agent option > whose Sub-opt-code is other than 1, 2, 3, 4, and 5, as described in > Section 3.3. > > 4> In page 14, case B, > > Old: > Any Home Network Information option which carries more than > one target MSP or which does not carry any target MSP MUST be > ignored. > > New: > > Any Home Network Information option which carries more than > one target MSP or which does not carry any target MSP MUST be > ignored. Otherwise, the DHCP server searches its database > by using the received target MSP as a key. > > 5> In page 15, the 8nd paragraph > > Old: > > The DHCP server should provide all of the matching home information > in Home Network Information option(s) based on its policy. It may > return partially matched results. For example, on receipt of a Home > Network Information option which specifies "xxx.example.com" as the > target network, it may return "example.com" to the mobile node. In > this case, "xxx.example.com" is returned in a sub-option with Sub- > opt-code 1, and "example.com" in a sub-option with Sub-opt-code 5. > Note that the detailed rule for returning partially matched instances > of home network information follows the server's own policy and is > outside the scope of this document. > > New: > > The DHCP server should provide all of the matching home information > in Home Network Information option(s) based on its policy. While > searching for the home network information by using the target MSP > as > a key, it may return the results when the key is partially matched. > For example, on receipt of a Home Network Information option which > specifies "xxx.example.com" as the target network, it may return the > home network information assigned for "example.com" to the mobile > node. Note that the detailed rule for returning partially matched > instances of home network information follows the server's own > policy > and is outside the scope of this document. > > 6> In Section 6 (IANA) > > Old: > o Home network identifier 1 > (only allowed in the Home Network > Information option; value Reserved > for the MIP6 Relay Agent option) > > New: > o Home network identifier 1 > > > Thanks for your kind help. > > - All the best > heejin. > > > ------- Original Message ------- > Sender : Jari Arkko > Date : 2008-05-20 01:12 (GMT+09:00) > Title : hiopt > > Hi all, > > I have reviewed this thread and re-reviewed the draft. While I > sympathize with some of the questions Alex had, I see no technical > reason to block the draft from being approved, and I see no support from > the WG from doing this either. So I am now approving the document. > > However, as a re-read the draft, I also noticed two additional issues. > The first issue is that Section 3 seems to be forgetting the case where > DHCP server has no information about a particular home network. Due to > this, I would like to make the following change: > > OLD: > In a network where the NAS is not co- > located with a DHCP relay nor a server, the server may not be > provided with the home network information from the NAS, and thereby > it may assign to a mobile node the home information which has been > preconfigured by the administrator or which is acquired through a > mechanism that is not described in this document. > NEW: > In a network where the NAS is not co- > located with a DHCP relay nor a server, the server may not be > provided with the home network information from the NAS, and thereby > it may either fail to provide information, or provide home information > which has been preconfigured by the administrator or which is acquired > through a mechanism that is not described in this document. > > Secondly, Section 4.2 and 4.3 talk about how relays can provide > information to servers. But I cannot see how the server knows which > piece of information from the relay corresponds to what Home Information > Option, in case there were multiple options with different home network > names. I am a bit uncertain how to fix this, however. Perhaps it is > necessary to allow suboption type 1 in relay agent options, too. > > Please suggest text, and I will place it in the RFC Editor note part of > the tracker and approve it. (Or you can submit a new version with these > fixes.) > > Jari > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed May 28 13:14:47 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D42BD3A682A; Wed, 28 May 2008 13:14:46 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31E823A682A for ; Wed, 28 May 2008 13:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MskA72ibWjqW for ; Wed, 28 May 2008 13:14:44 -0700 (PDT) Received: from web84301.mail.re1.yahoo.com (web84301.mail.re1.yahoo.com [69.147.74.180]) by core3.amsl.com (Postfix) with SMTP id E0F943A679C for ; Wed, 28 May 2008 13:14:43 -0700 (PDT) Received: (qmail 22363 invoked by uid 60001); 28 May 2008 20:14:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=KVK2o2e3EfNFw/pi2AZdsZOD/UKSnhpU0QJQ6xP++YJkDWhD1Oea/nxstjmzJRO6WuSpwx/vgZJ7Eg5LErLrByQe9gY3AkpLCCNaEfXTihuS98px5JrkH6auuRXzWReNsmbsagpltPJswtzK1K50Y4WT3/PpaMWJjeXuuek5B34=; X-YMail-OSG: 1FcJoOcVM1l2Rrs7izJzGXA8yiU9lRcdpmSPoRPXAxxRFX3X9bpyNaM.bgffs5EviXxjZC3dH1rHpZQojyl1jiXaqI5apviH_gusWtzSXlP.kUFjdduNEQ_b_Fw- Received: from [206.16.17.212] by web84301.mail.re1.yahoo.com via HTTP; Wed, 28 May 2008 13:14:51 PDT X-Mailer: YahooMailRC/975.41 YahooMailWebService/0.7.185 Date: Wed, 28 May 2008 13:14:51 -0700 (PDT) From: Behcet Sarikaya To: marcelo bagnulo braun MIME-Version: 1.0 Message-ID: <860077.22126.qm@web84301.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0272588507==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0272588507== Content-Type: multipart/alternative; boundary="0-32320523-1212005691=:22126" --0-32320523-1212005691=:22126 Content-Type: text/plain; charset=us-ascii Hi Marcelo, Using the so-called generic notification mechanisms if we are defining some control messages then we need to define what these messages are for, i.e. message semantics. Once we do that we realize that they need to be in most cases defined in separate documents and hence they are no longer generic. My 2 cents. Regards, Behcet ----- Original Message ---- From: marcelo bagnulo braun To: mext@ietf.org Cc: Julien Laganier Sent: Wednesday, May 28, 2008 8:12:48 AM Subject: [MEXT] Scope of generic notification Hi all, In our new charter we have a new item on a generic notification mechanism. During discussion over the last weeks, it seems to me that the WG needs to make a decision about what is the scope of the generic notification In summary, we need to decide which is the scope of the generic notification and what is the scope of the existing MH types. Essentially, what need to be as clear as possible are the criteria for using the generic notification and which is the criteria for using a MH type. We would kindly ask the WG to comment on this, so we can make a decision Next, i include some background information about how i see this, but feel free to completely ignore it. I guess that one way to scope the generic notification, we could first define what is the goal of the generic notification. From Sri's draft, for instance, my understanding is that the generic notification goal is to allow a mean to provide asynchronous messages. (i am not sure what asynchronous means in this context, but i assume that it means not included in a BU/BA exchange??). If that is the case, i don't see why we need this, since we can always use another mobility header and define new messages to be exchanged. From Vijay's email, i understand that one of the goals is to save MH types, since they are a scarce resource. That seems reasonable. Raj mentioned that Generic notification is to be used for non critical things. Other mentioned that this should only be used for send and discard things. Now, the next question then is when to use a new MH header and when to use the generic notification. I think the generic notification document needs to explicitly define its scope. I guess that the elements that should be taken into account for the definition of the scope are the message exchange supported by the generic notification, the security mode, others?. In the message exchange, the question is whether the generic notification is just a notification, a notification plus an ACK, reliable delivery (i.e. retransmission till the sender receives an ACK), or a more complex message exchange i.e. more than one message retransmitted in each direction. Now, one option would be to define the generic notification so broad that it is a mere extension of the MH type, so that we can encode more values in there, without much definition of the message format. Another option would be to define a query/response message format and scope the generic notification to this type of simple interactions. A third option would be to define a reliable delivery, whith tiemouts and retransmissions (slightly more complex than the previous one) Other options that support more complex message exchange could also be conceived. So, bottom line we need to clearly define the scope of the generic notification and when to use MH types for extnesions. This include the type of message exchange supported, the type of information conveyed (critical or just infoormation), security and so on. I think this is a high level disucssion that the WG needs to have before we can move forward with the generic notification and also with the binding revocation, since once we define what is the scope of generic notification and the MH type usage, we will be able to conclude in which category the binding revocation falls. Regards, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --0-32320523-1212005691=:22126 Content-Type: text/html; charset=us-ascii
Hi Marcelo,
  Using the so-called generic notification mechanisms if we are defining some control messages then we need to define what these messages are for, i.e. message semantics. Once we do that we realize that they need to be in most cases defined in separate documents and hence they are no longer generic.
  My 2 cents.

Regards,

Behcet
----- Original Message ----
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
To: mext@ietf.org
Cc: Julien Laganier <julien.IETF@laposte.net>
Sent: Wednesday, May 28, 2008 8:12:48 AM
Subject: [MEXT] Scope of generic notification

Hi all,

In our new charter we have a new item on a generic notification mechanism.
During discussion over the last weeks, it seems to me that the WG needs to
make a decision about what is the scope of the generic notification

In summary, we need to decide which is the scope of the generic
notification and what is the scope of the existing MH types.
Essentially, what need to be as clear as possible are the criteria
for using the generic notification and which is the criteria for
using a MH type.

We would kindly ask the WG to comment on this, so we can make a decision

Next, i include some background information about how i see this,
but feel free to completely ignore it.

I guess that one way to scope the generic notification, we could first
define what is the goal of the generic notification. From Sri's
draft, for instance, my understanding is that the generic
notification goal is to allow a mean to provide asynchronous
messages. (i am not sure what asynchronous means in this context,
but i assume that it means not included in a BU/BA exchange??).

If that is the case, i don't see why we need this, since we can always
use another mobility header and define new messages to be exchanged.
From Vijay's email, i understand that one of the goals is to save MH
types, since they are a scarce resource. That seems reasonable.
Raj mentioned that Generic notification is to be used for non critical
things. Other mentioned that this should only be used for send and
discard things.


Now, the next question then is when to use a new MH header and when to
use the generic notification. I think the generic notification document
needs to explicitly define its scope.

I guess that the elements that should be taken into account for the
definition of the scope are the message exchange supported by the
generic notification, the security mode, others?. In the message
exchange, the question is whether the generic notification is just a
notification, a notification plus an ACK, reliable delivery (i.e.
retransmission till the sender receives an ACK), or a more complex
message exchange i.e. more than one message retransmitted in each direction.

Now, one option would be to define the generic notification so broad
that it is a mere extension of the MH type, so that we can encode more
values in there, without much definition of the message format.

Another option would be to define a query/response message format and
scope the generic notification to this type of simple interactions.

A third option would be to define a reliable delivery, whith tiemouts
and retransmissions (slightly more complex than the previous one)

Other options that support more complex message exchange could also be
conceived.

So, bottom line we need to clearly define the scope of the generic
notification and when to use MH types for extnesions. This include the
type of message exchange supported, the type of information conveyed
(critical or just infoormation), security and so on. I think this is a
high level disucssion that the WG needs to have before we can move
forward with the generic notification and also with the binding
revocation, since once we define what is the scope of generic
notification and the MH type usage, we will be able to conclude in which
category the binding revocation falls.

Regards, marcelo




_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext
--0-32320523-1212005691=:22126-- --===============0272588507== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0272588507==-- From mext-bounces@ietf.org Wed May 28 13:26:40 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14F2D3A689C; Wed, 28 May 2008 13:26:40 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5C5C3A6899 for ; Wed, 28 May 2008 13:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIm2bTX-627T for ; Wed, 28 May 2008 13:26:37 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 67FD13A6CBA for ; Wed, 28 May 2008 13:25:39 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 May 2008 16:25:42 -0400 Message-ID: In-Reply-To: <483D5A50.1000208@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Scope of generic notification Thread-Index: AcjAxJmrBblR8NiLRsSqSYOj8rri7AAO1xMw References: <483D5A50.1000208@it.uc3m.es> From: "Vijay Devarapalli" To: "marcelo bagnulo braun" , Cc: Julien Laganier Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Marcelo, > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of marcelo bagnulo braun > In our new charter we have a new item on a generic > notification mechanism. > During discussion over the last weeks, it seems to me that > the WG needs to > make a decision about what is the scope of the generic notification > > In summary, we need to decide which is the scope of the generic > notification and what is the scope of the existing MH types. > Essentially, what need to be as clear as possible are the criteria > for using the generic notification and which is the criteria for > using a MH type. > > We would kindly ask the WG to comment on this, so we can make > a decision The generic notification draft should support all of the following - A simple notification message which you just send and forget about it. Does not affect the state of the binding cache - A notification message that requires an ack. You re-transmit until you get an ack or when you timeout - A notification message that does affect the binding cache state - Enable the use of IPsec protection for the notification message if required My understanding is that the current generic notification draft supports all of the above. > Raj mentioned that Generic notification is to be used for non > critical > things. I disagree with this. > Now, the next question then is when to use a new MH header > and when to > use the generic notification. I think the generic > notification document > needs to explicitly define its scope. I think we may have to go with case-by-case basis. It would be hard to set the criteria now. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed May 28 14:11:34 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F21453A6AC3; Wed, 28 May 2008 14:11:33 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8097A3A6A38 for ; Wed, 28 May 2008 14:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.353 X-Spam-Level: X-Spam-Status: No, score=-6.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i52Cs8gfgnMX for ; Wed, 28 May 2008 14:11:30 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id DD8823A6BC5 for ; Wed, 28 May 2008 14:11:29 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m4SLBTc07315; Wed, 28 May 2008 21:11:30 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 May 2008 16:11:11 -0500 Message-ID: In-Reply-To: <483D5A50.1000208@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Scope of generic notification Thread-Index: AcjAxOe6Fri1J6ckRpa8mF3GH5c1KQAQEhtA References: <483D5A50.1000208@it.uc3m.es> From: "Ahmad Muhanna" To: "marcelo bagnulo braun" , Cc: Julien Laganier Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcello, I believe defining the scope of the Generic Notification Message is important in order to avoid a very broad definition which could capture all of the existing and future MH type messages. IMO, the scope of the Generic Notification Message should be as follows: " A Notification Message of a simple event that is generic in nature and does not cause an immediate change to the state of the mobile node BCE. This also means that the notification message may indicate that the receiving node needs to acknowledge/respond to the Notification message. " In order to help advancing the discussion, the above definition could be used in a question form and people on the mailing list could: positively, neutral or negatively support. Cheers! Regards, Ahmad > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of marcelo bagnulo braun > Sent: Wednesday, May 28, 2008 8:13 AM > To: mext@ietf.org > Cc: Julien Laganier > Subject: [MEXT] Scope of generic notification > > Hi all, > > In our new charter we have a new item on a generic > notification mechanism. > During discussion over the last weeks, it seems to me that > the WG needs to make a decision about what is the scope of > the generic notification > > In summary, we need to decide which is the scope of the > generic notification and what is the scope of the existing MH types. > Essentially, what need to be as clear as possible are the > criteria for using the generic notification and which is the > criteria for using a MH type. > > We would kindly ask the WG to comment on this, so we can make > a decision > > Next, i include some background information about how i see > this, but feel free to completely ignore it. > > I guess that one way to scope the generic notification, we > could first define what is the goal of the generic > notification. From Sri's draft, for instance, my > understanding is that the generic notification goal is to > allow a mean to provide asynchronous messages. (i am not sure > what asynchronous means in this context, but i assume that it > means not included in a BU/BA exchange??). > > If that is the case, i don't see why we need this, since we > can always use another mobility header and define new > messages to be exchanged. > From Vijay's email, i understand that one of the goals is to > save MH types, since they are a scarce resource. That seems > reasonable. > Raj mentioned that Generic notification is to be used for non > critical things. Other mentioned that this should only be > used for send and discard things. > > > Now, the next question then is when to use a new MH header > and when to use the generic notification. I think the generic > notification document needs to explicitly define its scope. > > I guess that the elements that should be taken into account > for the definition of the scope are the message exchange > supported by the generic notification, the security mode, > others?. In the message exchange, the question is whether the > generic notification is just a notification, a notification > plus an ACK, reliable delivery (i.e. > retransmission till the sender receives an ACK), or a more > complex message exchange i.e. more than one message > retransmitted in each direction. > > Now, one option would be to define the generic notification > so broad that it is a mere extension of the MH type, so that > we can encode more values in there, without much definition > of the message format. > > Another option would be to define a query/response message > format and scope the generic notification to this type of > simple interactions. > > A third option would be to define a reliable delivery, whith > tiemouts and retransmissions (slightly more complex than the > previous one) > > Other options that support more complex message exchange > could also be conceived. > > So, bottom line we need to clearly define the scope of the > generic notification and when to use MH types for extnesions. > This include the type of message exchange supported, the type > of information conveyed (critical or just infoormation), > security and so on. I think this is a high level disucssion > that the WG needs to have before we can move forward with the > generic notification and also with the binding revocation, > since once we define what is the scope of generic > notification and the MH type usage, we will be able to > conclude in which category the binding revocation falls. > > Regards, marcelo > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed May 28 15:14:29 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50B983A682A; Wed, 28 May 2008 15:14:29 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 619893A682A for ; Wed, 28 May 2008 15:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.837 X-Spam-Level: X-Spam-Status: No, score=-2.837 tagged_above=-999 required=5 tests=[AWL=0.925, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xpzoW0xXq0V for ; Wed, 28 May 2008 15:14:27 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 2CBCD3A67F8 for ; Wed, 28 May 2008 15:14:27 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (227.45.217.87.dynamic.jazztel.es [87.217.45.227])by smtp02.uc3m.es (Postfix) with ESMTP id E8A6B39DE4A; Thu, 29 May 2008 00:14:34 +0200 (CEST) Message-ID: <483DD94A.6070705@it.uc3m.es> Date: Thu, 29 May 2008 00:14:34 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Vijay Devarapalli References: <483D5A50.1000208@it.uc3m.es> In-Reply-To: X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-26.4475 TC:1F TRN:48 TV:5.5.1026(15938.002) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, thank you for the input Vijay Devarapalli escribi=F3: > Hello Marcelo, > > = >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On = >> Behalf Of marcelo bagnulo braun >> = > = > = >> In our new charter we have a new item on a generic = >> notification mechanism. = >> During discussion over the last weeks, it seems to me that = >> the WG needs to = >> make a decision about what is the scope of the generic notification >> >> In summary, we need to decide which is the scope of the generic >> notification and what is the scope of the existing MH types. >> Essentially, what need to be as clear as possible are the criteria >> for using the generic notification and which is the criteria for >> using a MH type. >> >> We would kindly ask the WG to comment on this, so we can make = >> a decision >> = > > The generic notification draft should support all of the following > > - A simple notification message which you just send and forget about it. > Does not affect the state of the binding cache > - A notification message that requires an ack. You re-transmit until you > get an ack or when you timeout > - A notification message that does affect the binding cache state > - Enable the use of IPsec protection for the notification message if > required > > = so, are you saying that any new functionality that uses this type of = message exchange should use the generic notification and not a new MH? > My understanding is that the current generic notification draft supports > all of the above. = > > = >> Raj mentioned that Generic notification is to be used for non = >> critical = >> things. = >> = > > I disagree with this. > > = >> Now, the next question then is when to use a new MH header = >> and when to = >> use the generic notification. I think the generic = >> notification document = >> needs to explicitly define its scope. >> = > > I think we may have to go with case-by-case basis. It would be hard to > set the criteria now. > > = I find this hard to accept I mean, how are going to decide later? based on what if we don't define = a criteria? It should be possible to at least provide some guidance on = this. I am not saying we can define an selection algorithm, but some = guidance must be provided imho In other words, i guess you do have some abstract gut feeling on when to = use one and when to use the other one. this basically relies on some = conception of what the scope of the generic notification is. My proposal = is to try to make the excersise to state this ideas explicltly, so we = can all agree on this. I mean, past disucssion seems to show to me that = different people have very different ideas on what the generic = notification should be used for. Just specifying the format will not = solve this confusion and would result in problems in the future, since = people have different conception on this. We are better off if we state = the applicability of the generic up front now and include it in the document regards, marcelo > Vijay > > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed May 28 16:08:55 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0054328C165; Wed, 28 May 2008 16:08:54 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC85B28C182 for ; Wed, 28 May 2008 16:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqCi-rLk8Qr7 for ; Wed, 28 May 2008 16:08:52 -0700 (PDT) Received: from web84310.mail.re1.yahoo.com (web84310.mail.re1.yahoo.com [69.147.74.189]) by core3.amsl.com (Postfix) with SMTP id AEB4B28C165 for ; Wed, 28 May 2008 16:08:51 -0700 (PDT) Received: (qmail 12125 invoked by uid 60001); 28 May 2008 23:09:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=C43ekPF0aVJwair32FkOSIZ0vmamtLGdjnRYY7BHIHX0nC8LdErKYyPsPdQeNwGvuRyCnXIY1nJg4WzraDwzFaG8koKKDq3VXrQH4n3jEjdqguHYIzz2K4jKrQBKaFhEhqVnJohOw6n7sxyY6alx8zJoiOLiCALHroX3tBpf05s=; X-YMail-OSG: 77zQk.YVM1kxZslAMbxieZksP20N5hU.lnPxc.OAC0dzXJw7BL350m72h4tJvo0qOkhT8xIV8u1i97KqfQxwUtmpcd1dQZJ6uVs2C2_2_e_uiLFE_UI1JAzOTS0- Received: from [206.16.17.212] by web84310.mail.re1.yahoo.com via HTTP; Wed, 28 May 2008 16:08:59 PDT X-Mailer: YahooMailRC/975.41 YahooMailWebService/0.7.185 Date: Wed, 28 May 2008 16:08:59 -0700 (PDT) From: Behcet Sarikaya To: Ahmad Muhanna MIME-Version: 1.0 Message-ID: <286955.11920.qm@web84310.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0015387499==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0015387499== Content-Type: multipart/alternative; boundary="0-165314298-1212016139=:11920" --0-165314298-1212016139=:11920 Content-Type: text/plain; charset=us-ascii If this is about MH Type defined in RFC 3775 as an 8-bit field not being enough and that we need to define a MH Subtype, we should state that clearly. So I would support defining such a subtype and letting IANA to assign values. Why create confusion on trying to define things like notification/ generic, etc. message? Regards, Behcet ----- Original Message ---- From: Ahmad Muhanna To: marcelo bagnulo braun ; mext@ietf.org Cc: Julien Laganier Sent: Wednesday, May 28, 2008 4:11:11 PM Subject: Re: [MEXT] Scope of generic notification Hi Marcello, I believe defining the scope of the Generic Notification Message is important in order to avoid a very broad definition which could capture all of the existing and future MH type messages. IMO, the scope of the Generic Notification Message should be as follows: " A Notification Message of a simple event that is generic in nature and does not cause an immediate change to the state of the mobile node BCE. This also means that the notification message may indicate that the receiving node needs to acknowledge/respond to the Notification message. " In order to help advancing the discussion, the above definition could be used in a question form and people on the mailing list could: positively, neutral or negatively support. Cheers! Regards, Ahmad > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of marcelo bagnulo braun > Sent: Wednesday, May 28, 2008 8:13 AM > To: mext@ietf.org > Cc: Julien Laganier > Subject: [MEXT] Scope of generic notification > > Hi all, > > In our new charter we have a new item on a generic > notification mechanism. > During discussion over the last weeks, it seems to me that > the WG needs to make a decision about what is the scope of > the generic notification > > In summary, we need to decide which is the scope of the > generic notification and what is the scope of the existing MH types. > Essentially, what need to be as clear as possible are the > criteria for using the generic notification and which is the > criteria for using a MH type. > > We would kindly ask the WG to comment on this, so we can make > a decision > > Next, i include some background information about how i see > this, but feel free to completely ignore it. > > I guess that one way to scope the generic notification, we > could first define what is the goal of the generic > notification. From Sri's draft, for instance, my > understanding is that the generic notification goal is to > allow a mean to provide asynchronous messages. (i am not sure > what asynchronous means in this context, but i assume that it > means not included in a BU/BA exchange??). > > If that is the case, i don't see why we need this, since we > can always use another mobility header and define new > messages to be exchanged. > From Vijay's email, i understand that one of the goals is to > save MH types, since they are a scarce resource. That seems > reasonable. > Raj mentioned that Generic notification is to be used for non > critical things. Other mentioned that this should only be > used for send and discard things. > > > Now, the next question then is when to use a new MH header > and when to use the generic notification. I think the generic > notification document needs to explicitly define its scope. > > I guess that the elements that should be taken into account > for the definition of the scope are the message exchange > supported by the generic notification, the security mode, > others?. In the message exchange, the question is whether the > generic notification is just a notification, a notification > plus an ACK, reliable delivery (i.e. > retransmission till the sender receives an ACK), or a more > complex message exchange i.e. more than one message > retransmitted in each direction. > > Now, one option would be to define the generic notification > so broad that it is a mere extension of the MH type, so that > we can encode more values in there, without much definition > of the message format. > > Another option would be to define a query/response message > format and scope the generic notification to this type of > simple interactions. > > A third option would be to define a reliable delivery, whith > tiemouts and retransmissions (slightly more complex than the > previous one) > > Other options that support more complex message exchange > could also be conceived. > > So, bottom line we need to clearly define the scope of the > generic notification and when to use MH types for extnesions. > This include the type of message exchange supported, the type > of information conveyed (critical or just infoormation), > security and so on. I think this is a high level disucssion > that the WG needs to have before we can move forward with the > generic notification and also with the binding revocation, > since once we define what is the scope of generic > notification and the MH type usage, we will be able to > conclude in which category the binding revocation falls. > > Regards, marcelo > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --0-165314298-1212016139=:11920 Content-Type: text/html; charset=us-ascii
If this is about MH Type defined in RFC 3775 as an 8-bit field not being enough and that we need to define a MH Subtype, we should state that clearly. So I would support defining such a subtype and letting IANA to assign values.

Why create confusion on trying to define things like notification/ generic, etc. message?

Regards,

Behcet

----- Original Message ----
From: Ahmad Muhanna <amuhanna@nortel.com>
To: marcelo bagnulo braun <marcelo@it.uc3m.es>; mext@ietf.org
Cc: Julien Laganier <julien.IETF@laposte.net>
Sent: Wednesday, May 28, 2008 4:11:11 PM
Subject: Re: [MEXT] Scope of generic notification

Hi Marcello,

I believe defining the scope of the Generic Notification Message is
important in order to avoid a very broad definition which could capture
all of the existing and future MH type messages.

IMO, the scope of the Generic Notification Message should be as follows:

"
A Notification Message of a simple event that is generic in nature and
does not cause an immediate change to the state of the mobile node BCE.
This also means that the notification message may indicate that the
receiving node needs to acknowledge/respond to the Notification message.
"

In order to help advancing the discussion, the above definition could be
used in a question form and people on the mailing list could:
positively, neutral or negatively support.

Cheers!


Regards,
Ahmad


> -----Original Message-----
> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On
> Behalf Of marcelo bagnulo braun
> Sent: Wednesday, May 28, 2008 8:13 AM
> To: mext@ietf.org
> Cc: Julien Laganier
> Subject: [MEXT] Scope of generic notification
>
> Hi all,
>
> In our new charter we have a new item on a generic
> notification mechanism.
> During discussion over the last weeks, it seems to me that
> the WG needs to make a decision about what is the scope of
> the generic notification
>
> In summary, we need to decide which is the scope of the
> generic notification and what is the scope of the existing MH types.
> Essentially, what need to be as clear as possible are the
> criteria for using the generic notification and which is the
> criteria for using a MH type.
>
> We would kindly ask the WG to comment on this, so we can make
> a decision
>
> Next, i include some background information about how i see
> this, but feel free to completely ignore it.
>
> I guess that one way to scope the generic notification, we
> could first define what is the goal of the generic
> notification. From Sri's draft, for instance, my
> understanding is that the generic notification goal is to
> allow a mean to provide asynchronous messages. (i am not sure
> what asynchronous means in this context, but i assume that it
> means not included in a BU/BA exchange??).
>
> If that is the case, i don't see why we need this, since we
> can always use another mobility header and define new
> messages to be exchanged.
> From Vijay's email, i understand that one of the goals is to
> save MH types, since they are a scarce resource. That seems
> reasonable.
> Raj mentioned that Generic notification is to be used for non
> critical things. Other mentioned that this should only be
> used for send and discard things.
>
>
> Now, the next question then is when to use a new MH header
> and when to use the generic notification. I think the generic
> notification document needs to explicitly define its scope.
>
> I guess that the elements that should be taken into account
> for the definition of the scope are the message exchange
> supported by the generic notification, the security mode,
> others?. In the message exchange, the question is whether the
> generic notification is just a notification, a notification
> plus an ACK, reliable delivery (i.e.
> retransmission till the sender receives an ACK), or a more
> complex message exchange i.e. more than one message
> retransmitted in each direction.
>
> Now, one option would be to define the generic notification
> so broad that it is a mere extension of the MH type, so that
> we can encode more values in there, without much definition
> of the message format.
>
> Another option would be to define a query/response message
> format and scope the generic notification to this type of
> simple interactions.
>
> A third option would be to define a reliable delivery, whith
> tiemouts and retransmissions (slightly more complex than the
> previous one)
>
> Other options that support more complex message exchange
> could also be conceived.
>
> So, bottom line we need to clearly define the scope of the
> generic notification and when to use MH types for extnesions.
> This include the type of message exchange supported, the type
> of information conveyed (critical or just infoormation),
> security and so on. I think this is a high level disucssion
> that the WG needs to have before we can move forward with the
> generic notification and also with the binding revocation,
> since once we define what is the scope of generic
> notification and the MH type usage, we will be able to
> conclude in which category the binding revocation falls.
>
> Regards, marcelo
>
>
>
>
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
>
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext
--0-165314298-1212016139=:11920-- --===============0015387499== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0015387499==-- From mext-bounces@ietf.org Wed May 28 16:17:48 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BA653A6B15; Wed, 28 May 2008 16:17:48 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BC5C28C193 for ; Wed, 28 May 2008 16:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.394 X-Spam-Level: X-Spam-Status: No, score=-6.394 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaXwKUJHcOCm for ; Wed, 28 May 2008 16:17:45 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 34E373A6B15 for ; Wed, 28 May 2008 16:17:45 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m4SNHjc19022; Wed, 28 May 2008 23:17:45 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 May 2008 18:17:17 -0500 Message-ID: In-Reply-To: <286955.11920.qm@web84310.mail.re1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Scope of generic notification Thread-Index: AcjBF9VQKMYnyWjZRs2SJC7o+hFw7QAABAEg References: <286955.11920.qm@web84310.mail.re1.yahoo.com> From: "Ahmad Muhanna" To: "Behcet Sarikaya" Cc: mext@ietf.org Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1650385725==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --===============1650385725== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8C118.F8F5DBF3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8C118.F8F5DBF3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Behcet, =20 Actually, if the below scope is accepted, we probably do not need a new subtype filed to be defined and consequently, Generic Notification and Binding Revocation can advance in parallel using separate MH types. Again, it is quite important not to overload a single message to achieve many different functionalities. =20 Cheers! Regards,=20 Ahmad=20 =20 ________________________________ From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 Sent: Wednesday, May 28, 2008 6:09 PM To: Muhanna, Ahmad (RICH1:2H10) Cc: mext@ietf.org Subject: Re: [MEXT] Scope of generic notification =09 =09 If this is about MH Type defined in RFC 3775 as an 8-bit field not being enough and that we need to define a MH Subtype, we should state that clearly. So I would support defining such a subtype and letting IANA to assign values. =09 Why create confusion on trying to define things like notification/ generic, etc. message? =09 Regards, =09 Behcet =09 =09 ----- Original Message ---- From: Ahmad Muhanna To: marcelo bagnulo braun ; mext@ietf.org Cc: Julien Laganier Sent: Wednesday, May 28, 2008 4:11:11 PM Subject: Re: [MEXT] Scope of generic notification =09 Hi Marcello, =09 I believe defining the scope of the Generic Notification Message is important in order to avoid a very broad definition which could capture all of the existing and future MH type messages. =09 IMO, the scope of the Generic Notification Message should be as follows: =09 " A Notification Message of a simple event that is generic in nature and does not cause an immediate change to the state of the mobile node BCE. This also means that the notification message may indicate that the receiving node needs to acknowledge/respond to the Notification message. " =09 In order to help advancing the discussion, the above definition could be used in a question form and people on the mailing list could: positively, neutral or negatively support. =09 Cheers! =09 =09 Regards, Ahmad =09 =09 > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 > Behalf Of marcelo bagnulo braun > Sent: Wednesday, May 28, 2008 8:13 AM > To: mext@ietf.org > Cc: Julien Laganier > Subject: [MEXT] Scope of generic notification >=20 > Hi all, >=20 > In our new charter we have a new item on a generic=20 > notification mechanism.=20 > During discussion over the last weeks, it seems to me that=20 > the WG needs to make a decision about what is the scope of=20 > the generic notification >=20 > In summary, we need to decide which is the scope of the=20 > generic notification and what is the scope of the existing MH types. > Essentially, what need to be as clear as possible are the=20 > criteria for using the generic notification and which is the=20 > criteria for using a MH type. >=20 > We would kindly ask the WG to comment on this, so we can make=20 > a decision >=20 > Next, i include some background information about how i see=20 > this, but feel free to completely ignore it. >=20 > I guess that one way to scope the generic notification, we=20 > could first define what is the goal of the generic=20 > notification. From Sri's draft, for instance, my=20 > understanding is that the generic notification goal is to=20 > allow a mean to provide asynchronous messages. (i am not sure=20 > what asynchronous means in this context, but i assume that it=20 > means not included in a BU/BA exchange??). >=20 > If that is the case, i don't see why we need this, since we=20 > can always use another mobility header and define new=20 > messages to be exchanged.=20 > From Vijay's email, i understand that one of the goals is to=20 > save MH types, since they are a scarce resource. That seems=20 > reasonable.=20 > Raj mentioned that Generic notification is to be used for non=20 > critical things. Other mentioned that this should only be=20 > used for send and discard things. >=20 >=20 > Now, the next question then is when to use a new MH header=20 > and when to use the generic notification. I think the generic=20 > notification document needs to explicitly define its scope. >=20 > I guess that the elements that should be taken into account=20 > for the definition of the scope are the message exchange=20 > supported by the generic notification, the security mode,=20 > others?. In the message exchange, the question is whether the=20 > generic notification is just a notification, a notification=20 > plus an ACK, reliable delivery (i.e.=20 > retransmission till the sender receives an ACK), or a more=20 > complex message exchange i.e. more than one message=20 > retransmitted in each direction. >=20 > Now, one option would be to define the generic notification=20 > so broad that it is a mere extension of the MH type, so that=20 > we can encode more values in there, without much definition=20 > of the message format. >=20 > Another option would be to define a query/response message=20 > format and scope the generic notification to this type of=20 > simple interactions. >=20 > A third option would be to define a reliable delivery, whith=20 > tiemouts and retransmissions (slightly more complex than the=20 > previous one) >=20 > Other options that support more complex message exchange=20 > could also be conceived. >=20 > So, bottom line we need to clearly define the scope of the=20 > generic notification and when to use MH types for extnesions.=20 > This include the type of message exchange supported, the type=20 > of information conveyed (critical or just infoormation),=20 > security and so on. I think this is a high level disucssion=20 > that the WG needs to have before we can move forward with the=20 > generic notification and also with the binding revocation,=20 > since once we define what is the scope of generic=20 > notification and the MH type usage, we will be able to=20 > conclude in which category the binding revocation falls. >=20 > Regards, marcelo >=20 >=20 >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext >=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext =09 ------_=_NextPart_001_01C8C118.F8F5DBF3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Behcet,
 
Actually, if the below scope is accepted, we probably do not = need a new=20 subtype filed to be defined and consequently, Generic Notification and = Binding=20 Revocation can advance in parallel using separate MH types. Again, it is = quite=20 important not to overload a single message to achieve many = different=20 functionalities.
 
Cheers!

Regards, =
Ahmad

 

From: Behcet Sarikaya=20 [mailto:behcetsarikaya@yahoo.com]
Sent: Wednesday, May 28, = 2008=20 6:09 PM
To: Muhanna, Ahmad (RICH1:2H10)
Cc:=20 mext@ietf.org
Subject: Re: [MEXT] Scope of generic=20 notification

If=20 this is about MH Type defined in RFC 3775 as an 8-bit field not being = enough=20 and that we need to define a MH Subtype, we should state that clearly. = So I=20 would support defining such a subtype and letting IANA to assign=20 values.

Why create confusion on trying to define things like=20 notification/ generic, etc. = message?

Regards,

Behcet

-----=20 Original Message ----
From: Ahmad Muhanna=20 <amuhanna@nortel.com>
To: marcelo bagnulo braun=20 <marcelo@it.uc3m.es>; mext@ietf.org
Cc: Julien Laganier=20 <julien.IETF@laposte.net>
Sent: Wednesday, May 28, 2008 = 4:11:11=20 PM
Subject: Re: [MEXT] Scope of generic notification

Hi=20 Marcello,

I believe defining the scope of the Generic = Notification=20 Message is
important in order to avoid a very broad definition = which could=20 capture
all of the existing and future MH type = messages.

IMO, the=20 scope of the Generic Notification Message should be as = follows:

"
A=20 Notification Message of a simple event that is generic in nature = and
does=20 not cause an immediate change to the state of the mobile node = BCE.
This=20 also means that the notification message may indicate that = the
receiving=20 node needs to acknowledge/respond to the Notification = message.
"

In=20 order to help advancing the discussion, the above definition could = be
used=20 in a question form and people on the mailing list = could:
positively,=20 neutral or negatively=20 support.

Cheers!


Regards,
Ahmad


>=20 -----Original Message-----
> From: mext-bounces@ietf.org = [mailto:mext-bounces@ietf.org] On =
>=20 Behalf Of marcelo bagnulo braun
> Sent: Wednesday, May 28, 2008 = 8:13=20 AM
> To: mext@ietf.org
> Cc: Julien=20 Laganier
> Subject: [MEXT] Scope of generic notification
> =
> Hi all,
>
> In our new charter we have a new = item on a=20 generic
> notification mechanism.
> During discussion = over the=20 last weeks, it seems to me that
> the WG needs to make a = decision about=20 what is the scope of
> the generic notification
> =
> In=20 summary, we need to decide which is the scope of the
> generic=20 notification and what is the scope of the existing MH types.
>=20 Essentially, what need to be as clear as possible are the
> = criteria=20 for using the generic notification and which is the
> criteria = for=20 using a MH type.
>
> We would kindly ask the WG to = comment on=20 this, so we can make
> a decision
>
> Next, i = include some=20 background information about how i see
> this, but feel free to = completely ignore it.
>
> I guess that one way to scope = the=20 generic notification, we
> could first define what is the goal = of the=20 generic
> notification. From Sri's draft, for instance, my =
>=20 understanding is that the generic notification goal is to
> = allow a=20 mean to provide asynchronous messages. (i am not sure
> what=20 asynchronous means in this context, but i assume that it
> = means not=20 included in a BU/BA exchange??).
>
> If that is the case, = i don't=20 see why we need this, since we
> can always use another = mobility header=20 and define new
> messages to be exchanged.
> From = Vijay's email,=20 i understand that one of the goals is to
> save MH types, since = they=20 are a scarce resource. That seems
> reasonable.
> Raj = mentioned=20 that Generic notification is to be used for non
> critical = things.=20 Other mentioned that this should only be
> used for send and = discard=20 things.
>
>
> Now, the next question then is when = to use a=20 new MH header
> and when to use the generic notification. I = think the=20 generic
> notification document needs to explicitly define its=20 scope.
>
> I guess that the elements that should be taken = into=20 account
> for the definition of the scope are the message = exchange=20
> supported by the generic notification, the security mode, =
>=20 others?. In the message exchange, the question is whether the
> = generic=20 notification is just a notification, a notification
> plus an = ACK,=20 reliable delivery (i.e.
> retransmission till the sender = receives an=20 ACK), or a more
> complex message exchange i.e. more than one = message=20
> retransmitted in each direction.
>
> Now, one = option=20 would be to define the generic notification
> so broad that it = is a=20 mere extension of the MH type, so that
> we can encode more = values in=20 there, without much definition
> of the message format.
> =
> Another option would be to define a query/response message =
>=20 format and scope the generic notification to this type of
> = simple=20 interactions.
>
> A third option would be to define a = reliable=20 delivery, whith
> tiemouts and retransmissions (slightly more = complex=20 than the
> previous one)
>
> Other options that = support=20 more complex message exchange
> could also be = conceived.
>=20
> So, bottom line we need to clearly define the scope of the =
>=20 generic notification and when to use MH types for extnesions.
> = This=20 include the type of message exchange supported, the type
> of=20 information conveyed (critical or just infoormation),
> = security and so=20 on. I think this is a high level disucssion
> that the WG needs = to have=20 before we can move forward with the
> generic notification and = also=20 with the binding revocation,
> since once we define what is the = scope=20 of generic
> notification and the MH type usage, we will be = able to=20
> conclude in which category the binding revocation = falls.
>=20
> Regards, marcelo
>
>
>
>
>=20 _______________________________________________
> MEXT mailing=20 list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
> =
_______________________________________________
MEXT mailing = list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext
<= /DIV>
------_=_NextPart_001_01C8C118.F8F5DBF3-- --===============1650385725== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1650385725==-- From mext-bounces@ietf.org Wed May 28 16:46:42 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DFF63A6CCE; Wed, 28 May 2008 16:46:42 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7494A3A6CC1 for ; Wed, 28 May 2008 16:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXf+GE+f+6+r for ; Wed, 28 May 2008 16:46:37 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 08EF93A6CE1 for ; Wed, 28 May 2008 16:46:34 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 May 2008 18:33:54 -0400 Message-ID: In-Reply-To: <483DD94A.6070705@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Scope of generic notification Thread-Index: AcjBEDgZgRlbCE5CTeiqQpsxH7u57QAAJhIg References: <483D5A50.1000208@it.uc3m.es> <483DD94A.6070705@it.uc3m.es> From: "Vijay Devarapalli" To: "marcelo bagnulo braun" Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > > The generic notification draft should support all of the following > > > > - A simple notification message which you just send and > forget about it. > > Does not affect the state of the binding cache > > - A notification message that requires an ack. You > re-transmit until you > > get an ack or when you timeout > > - A notification message that does affect the binding cache state > > - Enable the use of IPsec protection for the notification message if > > required > > > so, are you saying that any new functionality that uses this type of > message exchange should use the generic notification and not a new MH? No. The generic notification message would support all of the above. Applications that make use of the generic notification message can decide whether they want an explicit acknowledgement (for example by setting the 'ack' flag) or IPsec protection (for example by having the SPD entries configured). > >> Now, the next question then is when to use a new MH header > >> and when to > >> use the generic notification. I think the generic > >> notification document > >> needs to explicitly define its scope. > > > > I think we may have to go with case-by-case basis. It would > be hard to > > set the criteria now. > > > I find this hard to accept > I mean, how are going to decide later? based on what if we > don't define > a criteria? It should be possible to at least provide some > guidance on > this. I am not saying we can define an selection algorithm, but some > guidance must be provided imho > > In other words, i guess you do have some abstract gut feeling > on when to > use one and when to use the other one. Right. > this basically relies on some > conception of what the scope of the generic notification is. > My proposal > is to try to make the excersise to state this ideas explicltly, so we > can all agree on this. Ok, I will bite. How about the following for the criteria? - The generic notification message can be used anytime you want to indicate/convey/modify something related to an existing session. Here I am assuming that a session corresponds to one instance of a binding cache entry for a particular mobile node. - The generic notification message can be used to trigger another node to setup a session. This would mean the trigger is sent to the recipient (mobile node or a MAG) to send a binding update (or a proxy binding update) and setup a session. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed May 28 17:19:58 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6D9D3A6CD3; Wed, 28 May 2008 17:19:58 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B61A33A6CD3 for ; Wed, 28 May 2008 17:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8foqGX6J7Z1w for ; Wed, 28 May 2008 17:19:57 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 3C3D53A6CCE for ; Wed, 28 May 2008 17:19:56 -0700 (PDT) Received: from localhost ([127.0.0.1]:36674 helo=chardonnay.local) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1K1VsA-0008IE-0Y; Thu, 29 May 2008 02:20:02 +0200 Message-ID: <483DF6B1.2070205@levkowetz.com> Date: Thu, 29 May 2008 02:20:01 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: marcelo bagnulo braun References: <483D5A50.1000208@it.uc3m.es> In-Reply-To: <483D5A50.1000208@it.uc3m.es> X-Enigmail-Version: 0.95.6 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: marcelo@it.uc3m.es, mext@ietf.org, julien.IETF@laposte.net, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcelo and all, On 2008-05-28 15:12 marcelo bagnulo braun said the following: ... > So, bottom line we need to clearly define the scope of the generic > notification and when to use MH types for extnesions. This include the > type of message exchange supported, the type of information conveyed > (critical or just infoormation), security and so on. I think this is a > high level disucssion that the WG needs to have before we can move > forward with the generic notification and also with the binding > revocation, since once we define what is the scope of generic > notification and the MH type usage, we will be able to conclude in which > category the binding revocation falls. I'm going to be a bit contrary here, as follows: I would expect the binding revocation to be a poster child, an excellent excellent example of something we know we want to do, which ought to fit well within a generic notifiation mechanism. If it is the case that the generic notification mechanism as currently proposed doesn't suit this use case, I think it's quite wrong to try to work out the scope of the current mechanism, and then decide whether it is suitable for binding revocation; what should be done is to look again at the proposed generic notification mechanism and see what it really should look like in order to be well suited to carry the binding revocation. If we have a notification mechanism which isn't suited for our primary example of a needed and wanted notification (the binding revocation), we can hardly call it generic, can we? Henrik _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed May 28 17:28:56 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 453343A6B5B; Wed, 28 May 2008 17:28:56 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD1473A6B5B for ; Wed, 28 May 2008 17:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u81KaL+J29uq for ; Wed, 28 May 2008 17:28:49 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 21FF43A6A80 for ; Wed, 28 May 2008 17:28:49 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id E61691E00A8 for ; Wed, 28 May 2008 20:28:54 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28513-18 for ; Wed, 28 May 2008 20:28:53 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 28 May 2008 20:28:53 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 May 2008 20:27:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 May 2008 20:28:19 -0400 Message-ID: <4D35478224365146822AE9E3AD4A266602941F01@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Scope of generic notification Thread-Index: AcjAxJmrBblR8NiLRsSqSYOj8rri7AAO1xMwAAhtxkA= From: "Koodli, Rajeev" To: "Vijay Devarapalli" , "marcelo bagnulo braun" , X-OriginalArrivalTime: 29 May 2008 00:27:26.0845 (UTC) FILETIME=[C59C1AD0:01C8C122] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: Julien Laganier Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, I am trying to understand the scope here. AFAICT, Generic Notification is, as it says, for generic usage. I can see it being useful in certain scenarios. However, it does not specify message trigger, events and semantics of the _specific_ protocol say between an HA and MN; it should not. If I have a Request/Reply sequence, it is not clear how/why I might be able to make use of this.. So, I am not sure why such a Request/Reply protocol should use, if any, what is specified in the GN draft. Thanks, -Rajeev > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Vijay Devarapalli > Sent: Wednesday, May 28, 2008 1:26 PM > To: marcelo bagnulo braun; mext@ietf.org > Cc: Julien Laganier > Subject: Re: [MEXT] Scope of generic notification > > Hello Marcelo, > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > Behalf Of marcelo bagnulo braun > > > In our new charter we have a new item on a generic > > notification mechanism. > > During discussion over the last weeks, it seems to me that > > the WG needs to > > make a decision about what is the scope of the generic notification > > > > In summary, we need to decide which is the scope of the generic > > notification and what is the scope of the existing MH types. > > Essentially, what need to be as clear as possible are the criteria > > for using the generic notification and which is the criteria for > > using a MH type. > > > > We would kindly ask the WG to comment on this, so we can make > > a decision > > The generic notification draft should support all of the following > > - A simple notification message which you just send and forget about it. > Does not affect the state of the binding cache > - A notification message that requires an ack. You re-transmit until you > get an ack or when you timeout > - A notification message that does affect the binding cache state > - Enable the use of IPsec protection for the notification message if > required > > My understanding is that the current generic notification draft supports > all of the above. > > > Raj mentioned that Generic notification is to be used for non > > critical > > things. > > I disagree with this. > > > Now, the next question then is when to use a new MH header > > and when to > > use the generic notification. I think the generic > > notification document > > needs to explicitly define its scope. > > I think we may have to go with case-by-case basis. It would be hard to > set the criteria now. > > Vijay > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed May 28 18:44:37 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABEA13A6CE5; Wed, 28 May 2008 18:44:37 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07C823A69BA for ; Wed, 28 May 2008 18:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaM+l74X6ybx for ; Wed, 28 May 2008 18:44:35 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id E1D7A3A6B0E for ; Wed, 28 May 2008 18:44:34 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 May 2008 20:47:08 -0400 Message-ID: In-Reply-To: <4D35478224365146822AE9E3AD4A266602941F01$0001@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Scope of generic notification Thread-Index: AcjAxJmrBblR8NiLRsSqSYOj8rri7AAO1xMwAAhtxkAAALykQA== References: <4D35478224365146822AE9E3AD4A266602941F01$0001@exchtewks3.starentnetworks.com> From: "Vijay Devarapalli" To: "Koodli, Rajeev" , "marcelo bagnulo braun" , Cc: Julien Laganier Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > I am trying to understand the scope here. > > AFAICT, Generic Notification is, as it says, for generic usage. ?? Not sure I follow. The way I see it, the generic notification message is a container to carry different types of notifications messages (identified by the Subtype field). What is "generic usage"?? > However, it does not specify message trigger, events and semantics of > the _specific_ protocol say between an HA and MN; it should not. The trigger and the semantics of the notification message identified by the "Subtype" field need to be specified as part of the protocol that is using the generic notification message. ?> If I > have a Request/Reply sequence, it is not clear how/why I might be able > to make use of this.. So, I am not sure why such a Request/Reply > protocol should use, if any, what is specified in the GN draft. If the "Request/Reply protocol" that you have in mind is trying to convey something about an existing session, then you should be using the generic notification message as the container. Vijay > > Thanks, > > -Rajeev > > > > -----Original Message----- > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf > Of > > Vijay Devarapalli > > Sent: Wednesday, May 28, 2008 1:26 PM > > To: marcelo bagnulo braun; mext@ietf.org > > Cc: Julien Laganier > > Subject: Re: [MEXT] Scope of generic notification > > > > Hello Marcelo, > > > > > -----Original Message----- > > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > > Behalf Of marcelo bagnulo braun > > > > > In our new charter we have a new item on a generic > > > notification mechanism. > > > During discussion over the last weeks, it seems to me that > > > the WG needs to > > > make a decision about what is the scope of the generic > notification > > > > > > In summary, we need to decide which is the scope of the generic > > > notification and what is the scope of the existing MH types. > > > Essentially, what need to be as clear as possible are the criteria > > > for using the generic notification and which is the criteria for > > > using a MH type. > > > > > > We would kindly ask the WG to comment on this, so we can make > > > a decision > > > > The generic notification draft should support all of the following > > > > - A simple notification message which you just send and forget about > it. > > Does not affect the state of the binding cache > > - A notification message that requires an ack. You re-transmit until > you > > get an ack or when you timeout > > - A notification message that does affect the binding cache state > > - Enable the use of IPsec protection for the notification message if > > required > > > > My understanding is that the current generic notification draft > supports > > all of the above. > > > > > Raj mentioned that Generic notification is to be used for non > > > critical > > > things. > > > > I disagree with this. > > > > > Now, the next question then is when to use a new MH header > > > and when to > > > use the generic notification. I think the generic > > > notification document > > > needs to explicitly define its scope. > > > > I think we may have to go with case-by-case basis. It would > be hard to > > set the criteria now. > > > > Vijay > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > "This email message and any attachments are confidential > information of Starent Networks, Corp. The information > transmitted may not be used to create or change any > contractual obligations of Starent Networks, Corp. Any > review, retransmission, dissemination or other use of, or > taking of any action in reliance upon this e-mail and its > attachments by persons or entities other than the intended > recipient is prohibited. If you are not the intended > recipient, please notify the sender immediately -- by > replying to this message or by sending an email to > postmaster@starentnetworks.com -- and destroy all copies of > this message and any attachments without reading or > disclosing their contents. Thank you." > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed May 28 19:41:44 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F7773A6A9D; Wed, 28 May 2008 19:41:44 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 104543A6978 for ; Wed, 28 May 2008 19:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zb-7Dj4KOFQ2 for ; Wed, 28 May 2008 19:41:41 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id A43B13A6976 for ; Wed, 28 May 2008 19:41:41 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id F23DBC8017 for ; Wed, 28 May 2008 22:41:47 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30219-19 for ; Wed, 28 May 2008 22:41:47 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 28 May 2008 22:41:47 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 May 2008 22:38:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 May 2008 22:39:03 -0400 Message-ID: <4D35478224365146822AE9E3AD4A266602941F1C@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Scope of generic notification Thread-Index: AcjAxJmrBblR8NiLRsSqSYOj8rri7AAO1xMwAAhtxkAAALykQAADQCOQ From: "Koodli, Rajeev" To: "Vijay Devarapalli" , "marcelo bagnulo braun" , X-OriginalArrivalTime: 29 May 2008 02:38:11.0801 (UTC) FILETIME=[09916490:01C8C135] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: Julien Laganier Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > > AFAICT, Generic Notification is, as it says, for generic usage. > > ?? Not sure I follow. The way I see it, the generic notification message > is a container to carry different types of notifications messages > (identified by the Subtype field). What is "generic usage"?? [RKo:>] I meant for generic notification purposes. > > > However, it does not specify message trigger, events and semantics of > > the _specific_ protocol say between an HA and MN; it should not. > > The trigger and the semantics of the notification message identified by > the "Subtype" field need to be specified as part of the protocol that is > using the generic notification message. > [RKo:>] That's okay. However, I see a concern wrt *scope*. What's the defense against "why don't you just use Generic Notification"? > ?> If I > > have a Request/Reply sequence, it is not clear how/why I might be able > > to make use of this.. So, I am not sure why such a Request/Reply > > protocol should use, if any, what is specified in the GN draft. > > If the "Request/Reply protocol" that you have in mind is trying to > convey something about an existing session, then you should be using the > generic notification message as the container. > [RKo:>] This is exactly what I am concerned about. "Convey" is vague, and could be interpreted non-uniformly. I don't think we need a "framework" that everyone must follow. If there is something useful in the spec, people will use it; we should not enforce. I am against making every protocol concerned with session management follow the generic notification model (because, very briefly, it is very hard to capture, let alone foresee, all the protocol requirements in a "generic" ID, no pun intended). -Rajeev > Vijay > > > > > Thanks, > > > > -Rajeev > > > > > > > -----Original Message----- > > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf > > Of > > > Vijay Devarapalli > > > Sent: Wednesday, May 28, 2008 1:26 PM > > > To: marcelo bagnulo braun; mext@ietf.org > > > Cc: Julien Laganier > > > Subject: Re: [MEXT] Scope of generic notification > > > > > > Hello Marcelo, > > > > > > > -----Original Message----- > > > > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > > > > Behalf Of marcelo bagnulo braun > > > > > > > In our new charter we have a new item on a generic > > > > notification mechanism. > > > > During discussion over the last weeks, it seems to me that > > > > the WG needs to > > > > make a decision about what is the scope of the generic > > notification > > > > > > > > In summary, we need to decide which is the scope of the generic > > > > notification and what is the scope of the existing MH types. > > > > Essentially, what need to be as clear as possible are the criteria > > > > for using the generic notification and which is the criteria for > > > > using a MH type. > > > > > > > > We would kindly ask the WG to comment on this, so we can make > > > > a decision > > > > > > The generic notification draft should support all of the following > > > > > > - A simple notification message which you just send and forget about > > it. > > > Does not affect the state of the binding cache > > > - A notification message that requires an ack. You re-transmit until > > you > > > get an ack or when you timeout > > > - A notification message that does affect the binding cache state > > > - Enable the use of IPsec protection for the notification message if > > > required > > > > > > My understanding is that the current generic notification draft > > supports > > > all of the above. > > > > > > > Raj mentioned that Generic notification is to be used for non > > > > critical > > > > things. > > > > > > I disagree with this. > > > > > > > Now, the next question then is when to use a new MH header > > > > and when to > > > > use the generic notification. I think the generic > > > > notification document > > > > needs to explicitly define its scope. > > > > > > I think we may have to go with case-by-case basis. It would > > be hard to > > > set the criteria now. > > > > > > Vijay > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > "This email message and any attachments are confidential > > information of Starent Networks, Corp. The information > > transmitted may not be used to create or change any > > contractual obligations of Starent Networks, Corp. Any > > review, retransmission, dissemination or other use of, or > > taking of any action in reliance upon this e-mail and its > > attachments by persons or entities other than the intended > > recipient is prohibited. If you are not the intended > > recipient, please notify the sender immediately -- by > > replying to this message or by sending an email to > > postmaster@starentnetworks.com -- and destroy all copies of > > this message and any attachments without reading or > > disclosing their contents. Thank you." > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Wed May 28 21:22:33 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 693293A6B2A; Wed, 28 May 2008 21:22:33 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E34233A6939 for ; Wed, 28 May 2008 21:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.423 X-Spam-Level: X-Spam-Status: No, score=-6.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8mV4qqSpXzR for ; Wed, 28 May 2008 21:22:30 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 86B853A6B2A for ; Wed, 28 May 2008 21:22:30 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m4T4MVQ21802; Thu, 29 May 2008 04:22:31 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 May 2008 23:21:40 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Scope of generic notification Thread-Index: AcjBEDgZgRlbCE5CTeiqQpsxH7u57QAAJhIgAAhNLpA= References: <483D5A50.1000208@it.uc3m.es> <483DD94A.6070705@it.uc3m.es> From: "Ahmad Muhanna" To: "Vijay Devarapalli" , "marcelo bagnulo braun" Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, Please see inline. Regards, Ahmad > > > > The generic notification draft should support all of the following > > > > > > - A simple notification message which you just send and > > forget about it. > > > Does not affect the state of the binding cache > > > - A notification message that requires an ack. You > > re-transmit until you > > > get an ack or when you timeout > > > - A notification message that does affect the binding cache state > > > - Enable the use of IPsec protection for the notification > message if > > > required > > > > > so, are you saying that any new functionality that uses > this type of > > message exchange should use the generic notification and > not a new MH? > > No. The generic notification message would support all of the above. > Applications that make use of the generic notification > message can decide whether they want an explicit > acknowledgement (for example by setting the 'ack' flag) or > IPsec protection (for example by having the SPD entries configured). [Ahmad] Hmmm.. How would all of the above be supported in a single shot? For example, how would this generic notification mechanism support the first very simple usecase "A simple notification message which you just send and forget about it", for example, your prepaid balance is $25.09. which MAY NOT require IPsec protection while at the same time support usecase 2 Which impact the BCE and require IPsec protection, while both use the same MH type? > > > >> Now, the next question then is when to use a new MH > header and when > > >> to use the generic notification. I think the generic > notification > > >> document needs to explicitly define its scope. > > > > > > I think we may have to go with case-by-case basis. It would > > be hard to > > > set the criteria now. > > > > > I find this hard to accept > > I mean, how are going to decide later? based on what if we don't > > define a criteria? It should be possible to at least provide some > > guidance on this. I am not saying we can define an selection > > algorithm, but some guidance must be provided imho > > > > In other words, i guess you do have some abstract gut > feeling on when > > to use one and when to use the other one. > > Right. > > > this basically relies on some > > conception of what the scope of the generic notification is. > > My proposal > > is to try to make the excersise to state this ideas > explicltly, so we > > can all agree on this. > > Ok, I will bite. How about the following for the criteria? > > - The generic notification message can be used anytime you > want to indicate/convey/modify something related to an > existing session. Here I am assuming that a session > corresponds to one instance of a binding cache entry for a > particular mobile node. > > - The generic notification message can be used to trigger > another node to setup a session. This would mean the trigger > is sent to the recipient (mobile node or a MAG) to send a > binding update (or a proxy binding > update) and setup a session. [Ahmad] On one hand, you said that "this should be addressed in a case-by-case because it would be hard to set the criteria now". In other words, you probably meant to say that it would be very difficult to capture the scope of this generic notification mechanism and its limitations at the present time. On the other hand, you just presented this very generic and broad scope that made me think it would be easier if you specify what has been left out. What I mean, if you define for us what is not included, we probably would understand what is included in this scope and luckily would be able to interpret what "indicate/convey/modify" and their combinations mean. > > Vijay > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 29 02:47:13 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22E323A68BE; Thu, 29 May 2008 02:47:13 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C07E73A691F for ; Thu, 29 May 2008 02:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gvyi-Gto2fmF for ; Thu, 29 May 2008 02:47:10 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id EE4553A68BE for ; Thu, 29 May 2008 02:47:09 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so3123448wfd.31 for ; Thu, 29 May 2008 02:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=4CDaP5i9mWb/vLwxoD1f5LLTs4jlRc5pYLYYV5YWAo0=; b=WV1NiId2V8BDUSKKuZrbJoXHbLYXn+UiBDMVNIU7yKRYxsaOUaxeoFY/yawahse2CoI3bfVfWaRja2iLn4jJUZSEU8r4MLqVLO3aKxed+bDWZIPZxaILndK+FB+ouaw4uvxlYVn6HL/aOjhXyBscsrFOVV0U+Mo/hqtDE4rS45w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qNYq+rZLjRtHZcffxwMcW2z0viPLbzNnNSUThtTi0BLeaPaj2j4yuj6Yu1BtCwBYwoEE/lLKf60U0RUoYyNQAWY00IHZulP8wGxY4UXl8j86mi5VBi+ZOl2PPNMT09aIyro2WKbVbZp3PHeYKOEKM3rELlQaRAOWh9w2COMggiQ= Received: by 10.142.13.14 with SMTP id 14mr601082wfm.234.1212054384507; Thu, 29 May 2008 02:46:24 -0700 (PDT) Received: by 10.142.240.12 with HTTP; Thu, 29 May 2008 02:46:24 -0700 (PDT) Message-ID: Date: Thu, 29 May 2008 10:46:24 +0100 From: "George Tsirtsis" To: "mext@ietf.org" In-Reply-To: <20080525121504.0794B3A6A2C@core3.amsl.com> MIME-Version: 1.0 Content-Disposition: inline References: <20080525121504.0794B3A6A2C@core3.amsl.com> Subject: Re: [MEXT] I-D Action:draft-ietf-mext-nemo-v4traversal-03.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hesham, I noticed some typos which you can fix whenever convinient. It looks like some initial letters have been omitted in several places e.g.: Page 36: " Home Agent SPD-S: F local_address = home_agent_1 & remote_address = home_address_1 & " I think this F is an "IF" and in page 37 " The above should result in BU/BA messages with the following BU received by the home agent. Pv4 header (src=V4ADDR, dst=HA_V4ADDR) UDP header (sport=Z, dport=DSMIPv6)" "Pv4" should be "IPv4" George 2008/5/25 : > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. > > > Title : Mobile IPv6 Support for Dual Stack Hosts and Routers > Author(s) : H. Soliman > Filename : draft-ietf-mext-nemo-v4traversal-03.txt > Pages : 48 > Date : 2008-05-25 > > The current Mobile IPv6 and NEMO specifications support IPv6 only. > This specification extends those standards to allow the registration > of IPv4 addresses and prefixes, respectively, and the transport of > both IPv4 and IPv6 packets over the tunnel to the home agent. This > specification also allows the Mobile Node to roam over both IPv6 and > IPv4, including the case where Network Address Translation is present > on the path between the mobile node and its home agent. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-v4traversal-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 29 04:17:49 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4085A3A6936; Thu, 29 May 2008 04:17:49 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A76C3A6B62 for ; Thu, 29 May 2008 04:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[RCVD_BAD_ID=2.088, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ai6lX6T-bnDL for ; Thu, 29 May 2008 04:17:31 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id C59833A6CDC for ; Thu, 29 May 2008 04:17:21 -0700 (PDT) Received: from dummyhost20.it.uc3m.es (unknown [163.117.139.215])by smtp01.uc3m.es (Postfix) with ESMTP id B13F7687539;Thu, 29 May 2008 13:17:19 +0200 (CEST) Message-ID: <483E90BF.9060909@it.uc3m.es> Date: Thu, 29 May 2008 13:17:19 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Henrik Levkowetz References: <483D5A50.1000208@it.uc3m.es> <483DF6B1.2070205@levkowetz.com> In-Reply-To: <483DF6B1.2070205@levkowetz.com> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-16.1302 TC:1F TRN:48 TV:5.5.1026(15938.006) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Henrik Levkowetz escribi=F3: > Hi Marcelo and all, > > On 2008-05-28 15:12 marcelo bagnulo braun said the following: > ... >> So, bottom line we need to clearly define the scope of the generic = >> notification and when to use MH types for extnesions. This include = >> the type of message exchange supported, the type of information = >> conveyed (critical or just infoormation), security and so on. I think = >> this is a high level disucssion that the WG needs to have before we = >> can move forward with the generic notification and also with the = >> binding revocation, since once we define what is the scope of generic = >> notification and the MH type usage, we will be able to conclude in = >> which category the binding revocation falls. > > I'm going to be a bit contrary here, as follows: > > I would expect the binding revocation to be a poster child, an excellent > excellent example of something we know we want to do, which ought to fit > well within a generic notifiation mechanism. Well, actually, my question is even one step before that. First of all, i am not talking about any generic notification draft, = just wnat to understadn what is the idea people have in mind when they = talk about generic notification. You seem to have a clear idea, since you think that the binding = revocation is one partcular case of generic notification, is that right? I was not even assuming that, (not that i have a problem with neither) = just want to understand what the scope of a generic notification should be So, what is the idea that you have about the generic notification that = makes you think that the binding revocation should fit in there? > > If it is the case that the generic notification mechanism as currently > proposed doesn't suit this use case, I think it's quite wrong to try to > work out the scope of the current mechanism, and then decide whether it > is suitable for binding revocation; what should be done is to look again > at the proposed generic notification mechanism and see what it really > should look like in order to be well suited to carry the binding = > revocation. > > If we have a notification mechanism which isn't suited for our primary > example of a needed and wanted notification (the binding revocation), we > can hardly call it generic, can we? > I fully agree with this, but i before that, i would like to agree on = what is the scope of the generic notification and when nw MH types = should be used. Once we have a clear view on the scope of each one, then we can see if = the binding revocation fits in the the generic notification scope or in = the new MH type scope, makes sense? regards, marcelo > > > Henrik > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 29 06:16:50 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22BD13A6914; Thu, 29 May 2008 06:16:50 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29A933A6914 for ; Thu, 29 May 2008 06:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99uzhyw985Ra for ; Thu, 29 May 2008 06:16:40 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 2E3FB3A686A for ; Thu, 29 May 2008 06:16:40 -0700 (PDT) Received: from localhost ([127.0.0.1]:51408 helo=brunello.autonomica.se) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1K1hze-0002IY-RI; Thu, 29 May 2008 15:16:34 +0200 Message-ID: <483EACB2.8030105@levkowetz.com> Date: Thu, 29 May 2008 15:16:34 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: marcelo bagnulo braun References: <483D5A50.1000208@it.uc3m.es> <483DF6B1.2070205@levkowetz.com> <483E90BF.9060909@it.uc3m.es> In-Reply-To: <483E90BF.9060909@it.uc3m.es> X-Enigmail-Version: 0.95.6 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: marcelo@it.uc3m.es, mext@ietf.org, julien.IETF@laposte.net, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcelo, On 2008-05-29 13:17 marcelo bagnulo braun said the following: > Henrik Levkowetz escribi=F3: >> Hi Marcelo and all, >> >> On 2008-05-28 15:12 marcelo bagnulo braun said the following: >> ... >>> So, bottom line we need to clearly define the scope of the generic = >>> notification and when to use MH types for extnesions. This include = >>> the type of message exchange supported, the type of information = >>> conveyed (critical or just infoormation), security and so on. I think = >>> this is a high level disucssion that the WG needs to have before we = >>> can move forward with the generic notification and also with the = >>> binding revocation, since once we define what is the scope of generic = >>> notification and the MH type usage, we will be able to conclude in = >>> which category the binding revocation falls. >> I'm going to be a bit contrary here, as follows: >> >> I would expect the binding revocation to be a poster child, an excellent >> excellent example of something we know we want to do, which ought to fit >> well within a generic notifiation mechanism. > = > Well, actually, my question is even one step before that. > First of all, i am not talking about any generic notification draft, = > just wnat to understadn what is the idea people have in mind when they = > talk about generic notification. > = > You seem to have a clear idea, since you think that the binding = > revocation is one partcular case of generic notification, is that right? > = > I was not even assuming that, (not that i have a problem with neither) = > just want to understand what the scope of a generic notification should be > = > So, what is the idea that you have about the generic notification that = > makes you think that the binding revocation should fit in there? Starting from the most basic idea, registration requests are initiated by the mobile node, to update a state at the home agent (and potentially the communicating nodes, but that's a refinement). Notifications are initiated by the home agent (and possibly other nodes, but that's a refinement) to update state at the mobile node (and possibly other nodes, but again that's a refinement). So a generic notification mechanism provides a complement to the reg. requests which makes it possible for other nodes than the mobile node to _initiate_ communication, rather than having to wait for the mobile node to do so. >> If it is the case that the generic notification mechanism as currently >> proposed doesn't suit this use case, I think it's quite wrong to try to >> work out the scope of the current mechanism, and then decide whether it >> is suitable for binding revocation; what should be done is to look again >> at the proposed generic notification mechanism and see what it really >> should look like in order to be well suited to carry the binding = >> revocation. >> >> If we have a notification mechanism which isn't suited for our primary >> example of a needed and wanted notification (the binding revocation), we >> can hardly call it generic, can we? >> > I fully agree with this, but i before that, i would like to agree on = > what is the scope of the generic notification and when nw MH types = > should be used. Here you seem to assume that a generic notification mechanism doesn't use the MH. I don't necessarily see it that way. > Once we have a clear view on the scope of each one, then we can see if = > the binding revocation fits in the the generic notification scope or in = > the new MH type scope, makes sense? Nope. You still assume that there are two mechanisms; I think that's not a situation I'd prefer to have. If we are going to use MH (which I strongly wish we hadn't defined at all in the first place) then maybe a notification mechanism should use the MH also. Things should be as simple as possible, but not simpler. Two communication mechanisms instead of one is already a noticeable complication. Maybe it's offset by other simplicities, but I would prefer not to start off with an assumption that there has to be two. Henrik _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 29 06:38:26 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87E813A6AC6; Thu, 29 May 2008 06:38:26 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AB453A686A for ; Thu, 29 May 2008 06:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.837 X-Spam-Level: X-Spam-Status: No, score=-2.837 tagged_above=-999 required=5 tests=[AWL=0.925, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AbNI5O4ajhT for ; Thu, 29 May 2008 06:38:19 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 90B433A6B74 for ; Thu, 29 May 2008 06:37:54 -0700 (PDT) Received: from dummyhost24.it.uc3m.es (dummyhost24.it.uc3m.es [163.117.139.215])by smtp03.uc3m.es (Postfix) with ESMTP id 45EF33CE2E9;Thu, 29 May 2008 15:37:52 +0200 (CEST) Message-ID: <483EB1B0.7030302@it.uc3m.es> Date: Thu, 29 May 2008 15:37:52 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Henrik Levkowetz References: <483D5A50.1000208@it.uc3m.es> <483DF6B1.2070205@levkowetz.com> <483E90BF.9060909@it.uc3m.es> <483EACB2.8030105@levkowetz.com> In-Reply-To: <483EACB2.8030105@levkowetz.com> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-25.9342 TC:1F TRN:71 TV:5.5.1026(15938.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Henrik Levkowetz escribi=F3: > Hi Marcelo, > > On 2008-05-29 13:17 marcelo bagnulo braun said the following: >> Henrik Levkowetz escribi=F3: >>> Hi Marcelo and all, >>> >>> On 2008-05-28 15:12 marcelo bagnulo braun said the following: >>> ... >>>> So, bottom line we need to clearly define the scope of the generic = >>>> notification and when to use MH types for extnesions. This include = >>>> the type of message exchange supported, the type of information = >>>> conveyed (critical or just infoormation), security and so on. I = >>>> think this is a high level disucssion that the WG needs to have = >>>> before we can move forward with the generic notification and also = >>>> with the binding revocation, since once we define what is the scope = >>>> of generic notification and the MH type usage, we will be able to = >>>> conclude in which category the binding revocation falls. >>> I'm going to be a bit contrary here, as follows: >>> >>> I would expect the binding revocation to be a poster child, an = >>> excellent >>> excellent example of something we know we want to do, which ought to = >>> fit >>> well within a generic notifiation mechanism. >> >> Well, actually, my question is even one step before that. >> First of all, i am not talking about any generic notification draft, = >> just wnat to understadn what is the idea people have in mind when = >> they talk about generic notification. >> >> You seem to have a clear idea, since you think that the binding = >> revocation is one partcular case of generic notification, is that right? >> >> I was not even assuming that, (not that i have a problem with = >> neither) just want to understand what the scope of a generic = >> notification should be >> >> So, what is the idea that you have about the generic notification = >> that makes you think that the binding revocation should fit in there? > > Starting from the most basic idea, registration requests are initiated > by the mobile node, to update a state at the home agent (and potentially > the communicating nodes, but that's a refinement). Notifications are > initiated by the home agent (and possibly other nodes, but that's a > refinement) to update state at the mobile node (and possibly other nodes, > but again that's a refinement). > > So a generic notification mechanism provides a complement to the reg. > requests which makes it possible for other nodes than the mobile node > to _initiate_ communication, rather than having to wait for the mobile > node to do so. so basically for you, any communication that is not initiated by the MN = should use the generic notification, is that correct? If that is the case, then it seems a quite well defined scope for = generic notification to me... > >>> If it is the case that the generic notification mechanism as currently >>> proposed doesn't suit this use case, I think it's quite wrong to try to >>> work out the scope of the current mechanism, and then decide whether it >>> is suitable for binding revocation; what should be done is to look = >>> again >>> at the proposed generic notification mechanism and see what it really >>> should look like in order to be well suited to carry the binding = >>> revocation. >>> >>> If we have a notification mechanism which isn't suited for our primary >>> example of a needed and wanted notification (the binding = >>> revocation), we >>> can hardly call it generic, can we? >>> >> I fully agree with this, but i before that, i would like to agree on = >> what is the scope of the generic notification and when nw MH types = >> should be used. > > Here you seem to assume that a generic notification mechanism doesn't > use the MH. I don't necessarily see it that way. I may have phrased this in the wrong way. I assume that the generic notification will use one MH type for econding it. But once that we have defined the generic notification with a given MH = type assigned to it, then for any new message that we want to exchange = we then have the option or either using the generic notification or to = use a new MH type for this. My question is then when to use the generic notification (with the MH = type assigned to the generic notification) and when to use a new MH = type, makes sese now or am i still missing something? > >> Once we have a clear view on the scope of each one, then we can see = >> if the binding revocation fits in the the generic notification scope = >> or in the new MH type scope, makes sense? > > Nope. You still assume that there are two mechanisms; I think that's not > a situation I'd prefer to have. If we are going to use MH (which I = > strongly > wish we hadn't defined at all in the first place) then maybe a = > notification > mechanism should use the MH also. Things should be as simple as = > possible, > but not simpler. Two communication mechanisms instead of one is already > a noticeable complication. Maybe it's offset by other simplicities, but > I would prefer not to start off with an assumption that there has to be > two. > I don't think i udnerstand your point here. I assume that when you need to define a new information that you want to = signal between MIPv6 entities, you will have the option of using a new = MH type for doing it, or to use the generic notification. What is the = assumption that i am making that could be omited? Regards, marcelo > > Henrik > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 29 06:48:00 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A4413A6C97; Thu, 29 May 2008 06:48:00 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 475123A69D4 for ; Thu, 29 May 2008 06:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXH6acSmpCSa for ; Thu, 29 May 2008 06:47:52 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 08D173A68C1 for ; Thu, 29 May 2008 06:47:51 -0700 (PDT) Received: from brunello.autonomica.se ([192.71.80.182]:59508) by merlot.tools.ietf.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1K1iTo-0004f2-Ak; Thu, 29 May 2008 15:47:48 +0200 Message-ID: <483EB3FF.1090602@levkowetz.com> Date: Thu, 29 May 2008 15:47:43 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: marcelo bagnulo braun References: <483D5A50.1000208@it.uc3m.es> <483DF6B1.2070205@levkowetz.com> <483E90BF.9060909@it.uc3m.es> <483EACB2.8030105@levkowetz.com> <483EB1B0.7030302@it.uc3m.es> In-Reply-To: <483EB1B0.7030302@it.uc3m.es> X-Enigmail-Version: 0.95.6 X-SA-Exim-Connect-IP: 192.71.80.182 X-SA-Exim-Rcpt-To: marcelo@it.uc3m.es, mext@ietf.org, julien.IETF@laposte.net, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Tue, 21 Aug 2007 23:39:36 +0000) X-SA-Exim-Scanned: Yes (on merlot.tools.ietf.org) Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcelo, On 2008-05-29 15:37 marcelo bagnulo braun said the following: > Henrik Levkowetz escribi=F3: ... >>> So, what is the idea that you have about the generic notification = >>> that makes you think that the binding revocation should fit in there? >> Starting from the most basic idea, registration requests are initiated >> by the mobile node, to update a state at the home agent (and potentially >> the communicating nodes, but that's a refinement). Notifications are >> initiated by the home agent (and possibly other nodes, but that's a >> refinement) to update state at the mobile node (and possibly other nodes, >> but again that's a refinement). >> >> So a generic notification mechanism provides a complement to the reg. >> requests which makes it possible for other nodes than the mobile node >> to _initiate_ communication, rather than having to wait for the mobile >> node to do so. > = > so basically for you, any communication that is not initiated by the MN = > should use the generic notification, is that correct? > = > If that is the case, then it seems a quite well defined scope for = > generic notification to me... Ok, good. >>>> If it is the case that the generic notification mechanism as currently >>>> proposed doesn't suit this use case, I think it's quite wrong to try to >>>> work out the scope of the current mechanism, and then decide whether it >>>> is suitable for binding revocation; what should be done is to look = >>>> again >>>> at the proposed generic notification mechanism and see what it really >>>> should look like in order to be well suited to carry the binding = >>>> revocation. >>>> >>>> If we have a notification mechanism which isn't suited for our primary >>>> example of a needed and wanted notification (the binding = >>>> revocation), we >>>> can hardly call it generic, can we? >>>> >>> I fully agree with this, but i before that, i would like to agree on = >>> what is the scope of the generic notification and when nw MH types = >>> should be used. >> Here you seem to assume that a generic notification mechanism doesn't >> use the MH. I don't necessarily see it that way. > I may have phrased this in the wrong way. > = > I assume that the generic notification will use one MH type for econding = it. Aha. That wasn't clear to me. Ok. > But once that we have defined the generic notification with a given MH = > type assigned to it, then for any new message that we want to exchange = > we then have the option or either using the generic notification or to = > use a new MH type for this. Umm... Yes. But if we have to use a new MH type for a communication between peers where the generic notification mechanism is available, that would lik= ely indicate a failure in designing the generic notification mechanism, no? > My question is then when to use the generic notification (with the MH = > type assigned to the generic notification) and when to use a new MH = > type, makes sese now or am i still missing something? No, I think I got you now. But to me that would mean that if you have to use a new MH type because the generic notification mechanism won't work, then you have failed to define the generic notification mechanism appropriately. If you wish to use a new MH type because the semantics is fundamentally different than what's been envisaged for the generic notification, that's fine. I have a hard time seeing that applying to binding revocation, though... >>> Once we have a clear view on the scope of each one, then we can see = >>> if the binding revocation fits in the the generic notification scope = >>> or in the new MH type scope, makes sense? >> Nope. You still assume that there are two mechanisms; I think that's not >> a situation I'd prefer to have. If we are going to use MH (which I = >> strongly >> wish we hadn't defined at all in the first place) then maybe a = >> notification >> mechanism should use the MH also. Things should be as simple as = >> possible, >> but not simpler. Two communication mechanisms instead of one is already >> a noticeable complication. Maybe it's offset by other simplicities, but >> I would prefer not to start off with an assumption that there has to be >> two. >> > I don't think i udnerstand your point here. > = > I assume that when you need to define a new information that you want to = > signal between MIPv6 entities, you will have the option of using a new = > MH type for doing it, or to use the generic notification. What is the = > assumption that i am making that could be omited? I think I understand you better now, so maybe none -- except for the reservation noted earlier (above) about not being able to use the generic notification if it's available being a design failure indication. Best, Henrik _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 29 07:12:56 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75B8A3A68BC; Thu, 29 May 2008 07:12:56 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 697603A6919 for ; Thu, 29 May 2008 07:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIB-3GJ3nWJ3 for ; Thu, 29 May 2008 07:12:49 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 0E54B3A6B9F for ; Thu, 29 May 2008 07:12:35 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m4TEC7Q14504; Thu, 29 May 2008 14:12:07 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 May 2008 09:11:48 -0500 Message-ID: In-Reply-To: <483EACB2.8030105@levkowetz.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Scope of generic notification Thread-Index: AcjBjk5mAlODG6o/RjebLvUNjKc0bgAARuwQ References: <483D5A50.1000208@it.uc3m.es> <483DF6B1.2070205@levkowetz.com> <483E90BF.9060909@it.uc3m.es> <483EACB2.8030105@levkowetz.com> From: "Ahmad Muhanna" To: "Henrik Levkowetz" , "marcelo bagnulo braun" Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Henrik, Please see inline. Regards, Ahmad = > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On = > Behalf Of Henrik Levkowetz > Sent: Thursday, May 29, 2008 8:17 AM > To: marcelo bagnulo braun > Cc: Julien Laganier; mext@ietf.org > Subject: Re: [MEXT] Scope of generic notification > = > Hi Marcelo, > = > On 2008-05-29 13:17 marcelo bagnulo braun said the following: > > Henrik Levkowetz escribi=F3: > >> Hi Marcelo and all, > >> > >> On 2008-05-28 15:12 marcelo bagnulo braun said the following: > >> ... > >>> So, bottom line we need to clearly define the scope of = > the generic = > >>> notification and when to use MH types for extnesions. = > This include = > >>> the type of message exchange supported, the type of information = > >>> conveyed (critical or just infoormation), security and so on. I = > >>> think this is a high level disucssion that the WG needs to have = > >>> before we can move forward with the generic notification and also = > >>> with the binding revocation, since once we define what is = > the scope = > >>> of generic notification and the MH type usage, we will be able to = > >>> conclude in which category the binding revocation falls. > >> I'm going to be a bit contrary here, as follows: > >> > >> I would expect the binding revocation to be a poster child, an = > >> excellent excellent example of something we know we want = > to do, which = > >> ought to fit well within a generic notifiation mechanism. > > = > > Well, actually, my question is even one step before that. > > First of all, i am not talking about any generic = > notification draft, = > > just wnat to understadn what is the idea people have in = > mind when they = > > talk about generic notification. > > = > > You seem to have a clear idea, since you think that the binding = > > revocation is one partcular case of generic notification, = > is that right? > > = > > I was not even assuming that, (not that i have a problem = > with neither) = > > just want to understand what the scope of a generic notification = > > should be > > = > > So, what is the idea that you have about the generic = > notification that = > > makes you think that the binding revocation should fit in there? > = > Starting from the most basic idea, registration requests are = > initiated by the mobile node, to update a state at the home = > agent (and potentially the communicating nodes, but that's a = > refinement). Notifications are initiated by the home agent = > (and possibly other nodes, but that's a > refinement) to update state at the mobile node (and possibly = > other nodes, but again that's a refinement). > = > So a generic notification mechanism provides a complement to the reg. > requests which makes it possible for other nodes than the = > mobile node to _initiate_ communication, rather than having = > to wait for the mobile node to do so. [Ahmad] It seems that you are using MIP4 terminologies here, but that is fine as lo= ng as we take it in the context of MEXT. Looking at the paragraph above, I have the following comments/questions: 1. It seems to me that there is something missing. How a generic notificati= on MECHANISM is complement to reg. requests? 2. In order to understand this a little better, could you explain what is "= generic"? , i.e. message, the mechanism, etc. = 3. Why we need to call it notification, is there anything specific to this = name for example? > = > >> If it is the case that the generic notification mechanism as = > >> currently proposed doesn't suit this use case, I think it's quite = > >> wrong to try to work out the scope of the current = > mechanism, and then = > >> decide whether it is suitable for binding revocation; what = > should be = > >> done is to look again at the proposed generic notification = > mechanism = > >> and see what it really should look like in order to be = > well suited to = > >> carry the binding revocation. > >> > >> If we have a notification mechanism which isn't suited for our = > >> primary example of a needed and wanted notification (the binding = > >> revocation), we can hardly call it generic, can we? > >> > > I fully agree with this, but i before that, i would like to = > agree on = > > what is the scope of the generic notification and when nw MH types = > > should be used. > = > Here you seem to assume that a generic notification mechanism = > doesn't use the MH. I don't necessarily see it that way. > = > > Once we have a clear view on the scope of each one, then we = > can see if = > > the binding revocation fits in the the generic notification = > scope or = > > in the new MH type scope, makes sense? > = > Nope. You still assume that there are two mechanisms; I = > think that's not a situation I'd prefer to have. If we are = > going to use MH (which I strongly wish we hadn't defined at = > all in the first place) then maybe a notification mechanism = > should use the MH also. = [Ahmad] It seems that you think that "generic" and "notification" refer to the mech= anism rather than the message. Is that true? > Things should be as simple as = > possible, but not simpler. Two communication mechanisms = > instead of one is already a noticeable complication. = [Ahmad] Please correct me if I am wrong. It seems to me here that what you have in = mind, as you probably mentioned earlier, as the primary target for your und= erstanding of the generic notification mechanism, is binding revocation. Pl= ease note, I used "mechanism" here to be consistent of what I understood fr= om what you said. If that is not accurate please let me know. > Maybe = > it's offset by other simplicities, but I would prefer not to = > start off with an assumption that there has to be two. > = > = > Henrik > = > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 29 07:23:53 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93E3B3A6BAE; Thu, 29 May 2008 07:23:53 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C4323A6BA6 for ; Thu, 29 May 2008 07:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[AWL=0.462, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Igp-URTNSKMT for ; Thu, 29 May 2008 07:23:47 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 708BE3A6B57 for ; Thu, 29 May 2008 07:23:47 -0700 (PDT) Received: from dummyhost24.it.uc3m.es (unknown [163.117.139.215])by smtp03.uc3m.es (Postfix) with ESMTP id 8D8573CDCE9;Thu, 29 May 2008 16:23:45 +0200 (CEST) Message-ID: <483EBC71.70102@it.uc3m.es> Date: Thu, 29 May 2008 16:23:45 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Henrik Levkowetz References: <483D5A50.1000208@it.uc3m.es> <483DF6B1.2070205@levkowetz.com> <483E90BF.9060909@it.uc3m.es> <483EACB2.8030105@levkowetz.com> <483EB1B0.7030302@it.uc3m.es> <483EB3FF.1090602@levkowetz.com> In-Reply-To: <483EB3FF.1090602@levkowetz.com> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-23.1300 TC:1F TRN:58 TV:5.5.1026(15938.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Henrik Levkowetz escribi=F3: > > Umm... Yes. But if we have to use a new MH type for a communication = > between > peers where the generic notification mechanism is available, that = > would likely > indicate a failure in designing the generic notification mechanism, no? > well, it depends on what do you think it is scope for generic = notification hence this discussion. You can envisage that generic notification is only for non reliable = delivery of information. So, you can scope it that way, and the it is = very clear: any information flowing from the HA that needs no reliable = ddelivery, you should use generic notification. Else you should use a = new MH type. (that is merely an example) OTOH, you can define the scope being much broader, that i think is what = you have in mind i.e. any information cnoveyed from the HA to the MN = should use the generic notification. New MH types are reserved for = information sent from the MN i guess then. We should then define the = generic notification format in a much more general way, that can = accomodate all kind of message exchange initiated by the HA and all king = of security and so on. I understand that your preference is that the generic notiication = emssage should be able to accomodate any information exchange initiated = by the HA, is that correct? I am perfectly ok with any of these or other options. My only point is = that the WG should define what the scope of the generic notification is >> My question is then when to use the generic notification (with the MH = >> type assigned to the generic notification) and when to use a new MH = >> type, makes sese now or am i still missing something? > > No, I think I got you now. But to me that would mean that if you have to > use a new MH type because the generic notification mechanism won't work, > then you have failed to define the generic notification mechanism > appropriately. > > If you wish to use a new MH type because the semantics is fundamentally > different than what's been envisaged for the generic notification, that's > fine. I have a hard time seeing that applying to binding revocation, > though... > I would leave the binding revocation discussion out of this for now. = Once we agreed on what the scope of the generic notification should be, = it should be fairly easy to understand if the binding revocation should = use it or not i guess >>>> Once we have a clear view on the scope of each one, then we can see = >>>> if the binding revocation fits in the the generic notification = >>>> scope or in the new MH type scope, makes sense? >>> Nope. You still assume that there are two mechanisms; I think = >>> that's not >>> a situation I'd prefer to have. If we are going to use MH (which I = >>> strongly >>> wish we hadn't defined at all in the first place) then maybe a = >>> notification >>> mechanism should use the MH also. Things should be as simple as = >>> possible, >>> but not simpler. Two communication mechanisms instead of one is = >>> already >>> a noticeable complication. Maybe it's offset by other simplicities, = >>> but >>> I would prefer not to start off with an assumption that there has to be >>> two. >>> >> I don't think i udnerstand your point here. >> >> I assume that when you need to define a new information that you want = >> to signal between MIPv6 entities, you will have the option of using a = >> new MH type for doing it, or to use the generic notification. What is = >> the assumption that i am making that could be omited? > > I think I understand you better now, so maybe none -- except for the > reservation noted earlier (above) about not being able to use the > generic notification if it's available being a design failure indication. > > > Best, > > Henrik > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 29 08:42:57 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E53CB28C172; Thu, 29 May 2008 08:42:56 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E1A23A69D1 for ; Thu, 29 May 2008 08:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fknhiXoVaSg3 for ; Thu, 29 May 2008 08:42:53 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id E3B093A6B81 for ; Thu, 29 May 2008 08:42:52 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m4TFgkQ29818; Thu, 29 May 2008 15:42:46 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 May 2008 10:42:44 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Scope of generic notification Thread-Index: AcjAxOe6Fri1J6ckRpa8mF3GH5c1KQA28ngAAAAvnhA= From: "Mohamed Khalil" To: , Cc: julien.IETF@laposte.net Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcelo, Subject: [MEXT] Scope of generic notification Raj mentioned that Generic notification is to be used for non critical things. Other mentioned that this should only be used for send and discard things. [MK] I agree with this as a scope for Generic Notification. Regards Mohamed _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 29 08:45:40 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9BF928C0EA; Thu, 29 May 2008 08:45:40 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A131B3A6A79 for ; Thu, 29 May 2008 08:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lgkf8xwmA0a for ; Thu, 29 May 2008 08:45:27 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 6D6823A6B57 for ; Thu, 29 May 2008 08:45:17 -0700 (PDT) Received: from localhost ([127.0.0.1]:56098 helo=chardonnay.local) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1K1kJV-0001bN-TU; Thu, 29 May 2008 17:45:14 +0200 Message-ID: <483ECF89.1040806@levkowetz.com> Date: Thu, 29 May 2008 17:45:13 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: marcelo bagnulo braun References: <483D5A50.1000208@it.uc3m.es> <483DF6B1.2070205@levkowetz.com> <483E90BF.9060909@it.uc3m.es> <483EACB2.8030105@levkowetz.com> <483EB1B0.7030302@it.uc3m.es> <483EB3FF.1090602@levkowetz.com> <483EBC71.70102@it.uc3m.es> In-Reply-To: <483EBC71.70102@it.uc3m.es> X-Enigmail-Version: 0.95.6 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: marcelo@it.uc3m.es, mext@ietf.org, julien.IETF@laposte.net, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcelo, On 2008-05-29 16:23 marcelo bagnulo braun said the following: > Henrik Levkowetz escribi=F3: >> Umm... Yes. But if we have to use a new MH type for a communication = >> between >> peers where the generic notification mechanism is available, that = >> would likely >> indicate a failure in designing the generic notification mechanism, no? >> > well, it depends on what do you think it is scope for generic = > notification hence this discussion. > = > You can envisage that generic notification is only for non reliable = > delivery of information. So, you can scope it that way, and the it is = > very clear: any information flowing from the HA that needs no reliable = > ddelivery, you should use generic notification. Else you should use a = > new MH type. (that is merely an example) > = > OTOH, you can define the scope being much broader, that i think is what = > you have in mind i.e. any information cnoveyed from the HA to the MN = > should use the generic notification. New MH types are reserved for = > information sent from the MN i guess then. We should then define the = > generic notification format in a much more general way, that can = > accomodate all kind of message exchange initiated by the HA and all king = > of security and so on. > = > I understand that your preference is that the generic notiication = > emssage should be able to accomodate any information exchange initiated = > by the HA, is that correct? No, I think I've still not quite managed to get across what I'm trying to say. I'm not advocating any specific property of the generic notificati= on mechanism, except that it should be generic. I'm advocating that it should (in addition to being somewhat generic) be *useful* for the use case (or cases) we know about today. More below. > I am perfectly ok with any of these or other options. My only point is = > that the WG should define what the scope of the generic notification is > = >>> My question is then when to use the generic notification (with the MH = >>> type assigned to the generic notification) and when to use a new MH = >>> type, makes sese now or am i still missing something? >> No, I think I got you now. But to me that would mean that if you have to >> use a new MH type because the generic notification mechanism won't work, >> then you have failed to define the generic notification mechanism >> appropriately. >> >> If you wish to use a new MH type because the semantics is fundamentally >> different than what's been envisaged for the generic notification, that's >> fine. I have a hard time seeing that applying to binding revocation, >> though... >> > I would leave the binding revocation discussion out of this for now. = > Once we agreed on what the scope of the generic notification should be, = > it should be fairly easy to understand if the binding revocation should = > use it or not i guess No no no. This is the point. We can define a beautiful mechanism which could be useless, or only useful for things which isn't really needed by anybody. I don't think that's what we should do, though. How many specific examples do we have of proposed messages with real deployment needs behind them? Discussing the properties of a message mechanism out of context of the specific examples which we know are needed today may lead to a beautiful but useless design. Discussing the properties of the message mechanism in the context of known use cases is vital, in order to get something with a reasonable chance of actually being appropriate and useful. Divorcing the generic notification mechanism from the most obvious potential use case for the mechanism doesn't make sense to me. Regards, Henrik _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 29 09:18:45 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 980B63A6AF2; Thu, 29 May 2008 09:18:45 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFDFF3A699A for ; Thu, 29 May 2008 09:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFpgt2Hs21hN for ; Thu, 29 May 2008 09:18:42 -0700 (PDT) Received: from bay0-omc2-s26.bay0.hotmail.com (bay0-omc2-s26.bay0.hotmail.com [65.54.246.162]) by core3.amsl.com (Postfix) with ESMTP id 7F9303A6A1E for ; Thu, 29 May 2008 09:18:42 -0700 (PDT) Received: from BAY142-W15 ([65.55.153.50]) by bay0-omc2-s26.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 May 2008 09:18:38 -0700 Message-ID: X-Originating-IP: [72.242.162.25] From: ariel silverstone To: Henrik Levkowetz , marcelo bagnulo braun Date: Thu, 29 May 2008 12:18:38 -0400 Importance: Normal In-Reply-To: <483ECF89.1040806@levkowetz.com> References: <483D5A50.1000208@it.uc3m.es> <483DF6B1.2070205@levkowetz.com> <483E90BF.9060909@it.uc3m.es> <483EACB2.8030105@levkowetz.com> <483EB1B0.7030302@it.uc3m.es> <483EB3FF.1090602@levkowetz.com> <483EBC71.70102@it.uc3m.es> <483ECF89.1040806@levkowetz.com> MIME-Version: 1.0 X-OriginalArrivalTime: 29 May 2008 16:18:38.0873 (UTC) FILETIME=[A7307890:01C8C1A7] Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1012953970==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1012953970== Content-Type: multipart/alternative; boundary="_91dfc6f6-a074-4cbf-8089-fe6b7a7a13b8_" --_91dfc6f6-a074-4cbf-8089-fe6b7a7a13b8_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To me, the following comment below is key: " If you wish to use a new MH type because the semantics is fundamentally >> different than what's been envisaged for the generic notification, that'= s >> fine. I have a hard time seeing that applying to binding revocation, >> though..." 1) I believe it should stay generic, unless we are aiming to solve a proble= m so different that we need to create what would become a new standard. 2) We should do something that is extensible - in this context I mean that = we will have an option to set a flag to refer to another field. 3) This inline (vs. out of band) discussion is not atypical to all communic= ations format. When I think of the use cases, especially by network device= s, I believe we should stick with the inline option. Ariel Silvestone > Date: Thu, 29 May 2008 17:45:13 +0200 > From: henrik@levkowetz.com > To: marcelo@it.uc3m.es > CC: julien.IETF@laposte.net; mext@ietf.org > Subject: Re: [MEXT] Scope of generic notification >=20 > Hi Marcelo, >=20 > On 2008-05-29 16:23 marcelo bagnulo braun said the following: > > Henrik Levkowetz escribi=F3: > >> Umm... Yes. But if we have to use a new MH type for a communication=20 > >> between > >> peers where the generic notification mechanism is available, that=20 > >> would likely > >> indicate a failure in designing the generic notification mechanism, no= ? > >> > > well, it depends on what do you think it is scope for generic=20 > > notification hence this discussion. > >=20 > > You can envisage that generic notification is only for non reliable=20 > > delivery of information. So, you can scope it that way, and the it is=20 > > very clear: any information flowing from the HA that needs no reliable= =20 > > ddelivery, you should use generic notification. Else you should use a=20 > > new MH type. (that is merely an example) > >=20 > > OTOH, you can define the scope being much broader, that i think is what= =20 > > you have in mind i.e. any information cnoveyed from the HA to the MN=20 > > should use the generic notification. New MH types are reserved for=20 > > information sent from the MN i guess then. We should then define the=20 > > generic notification format in a much more general way, that can=20 > > accomodate all kind of message exchange initiated by the HA and all kin= g=20 > > of security and so on. > >=20 > > I understand that your preference is that the generic notiication=20 > > emssage should be able to accomodate any information exchange initiated= =20 > > by the HA, is that correct? >=20 > No, I think I've still not quite managed to get across what I'm trying > to say. I'm not advocating any specific property of the generic notifica= tion > mechanism, except that it should be generic. I'm advocating that it shou= ld > (in addition to being somewhat generic) be *useful* for the use case (or > cases) we know about today. More below. >=20 > > I am perfectly ok with any of these or other options. My only point is= =20 > > that the WG should define what the scope of the generic notification is > >=20 > >>> My question is then when to use the generic notification (with the MH= =20 > >>> type assigned to the generic notification) and when to use a new MH=20 > >>> type, makes sese now or am i still missing something? > >> No, I think I got you now. But to me that would mean that if you have= to > >> use a new MH type because the generic notification mechanism won't wor= k, > >> then you have failed to define the generic notification mechanism > >> appropriately. > >> > >> If you wish to use a new MH type because the semantics is fundamentall= y > >> different than what's been envisaged for the generic notification, tha= t's > >> fine. I have a hard time seeing that applying to binding revocation, > >> though... > >> > > I would leave the binding revocation discussion out of this for now.=20 > > Once we agreed on what the scope of the generic notification should be,= =20 > > it should be fairly easy to understand if the binding revocation should= =20 > > use it or not i guess >=20 > No no no. This is the point. We can define a beautiful mechanism > which could be useless, or only useful for things which isn't really > needed by anybody. I don't think that's what we should do, though. >=20 > How many specific examples do we have of proposed messages with real > deployment needs behind them? >=20 > Discussing the properties of a message mechanism out of context of the > specific examples which we know are needed today may lead to a beautiful > but useless design. Discussing the properties of the message mechanism > in the context of known use cases is vital, in order to get something wit= h > a reasonable chance of actually being appropriate and useful. Divorcing > the generic notification mechanism from the most obvious potential use > case for the mechanism doesn't make sense to me. >=20 >=20 > Regards, >=20 > Henrik >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext --_91dfc6f6-a074-4cbf-8089-fe6b7a7a13b8_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To me, the following comment below is key:

"
If you wish to =
use a new MH type because the semantics is fundamentally
>> differ=
ent than what's been envisaged for the generic notification, that's
>=
> fine.  I have a hard time seeing that applying to binding revocation,<=
br>>> though..."

1) I believe it should stay generic, unless w=
e are aiming to solve a problem so different that we need to create what wo=
uld become a new standard.
2) We should do something that is extensible =
- in this context I mean that we will have an option to set a flag to refer=
 to another field.
3) This inline (vs. out of band) discussion is not at=
ypical to all communications format.  When I think of the use cases, especi=
ally by network devices, I believe we should stick with the inline option.<=
br>
Ariel Silvestone

> Date: Thu, 29 May 2008 17:45:13 += 0200
> From: henrik@levkowetz.com
> To: marcelo@it.uc3m.es
&= gt; CC: julien.IETF@laposte.net; mext@ietf.org
> Subject: Re: [MEXT] = Scope of generic notification
>
> Hi Marcelo,
>
>= On 2008-05-29 16:23 marcelo bagnulo braun said the following:
> >= Henrik Levkowetz escribi=F3:
> >> Umm... Yes. But if we have = to use a new MH type for a communication
> >> between
> = >> peers where the generic notification mechanism is available, that =
> >> would likely
> >> indicate a failure in desig= ning the generic notification mechanism, no?
> >>
> > = well, it depends on what do you think it is scope for generic
> >= notification hence this discussion.
> >
> > You can env= isage that generic notification is only for non reliable
> > deli= very of information. So, you can scope it that way, and the it is
> = > very clear: any information flowing from the HA that needs no reliable=
> > ddelivery, you should use generic notification. Else you sho= uld use a
> > new MH type. (that is merely an example)
> &g= t;
> > OTOH, you can define the scope being much broader, that i = think is what
> > you have in mind i.e. any information cnoveyed = from the HA to the MN
> > should use the generic notification. Ne= w MH types are reserved for
> > information sent from the MN i gu= ess then. We should then define the
> > generic notification form= at in a much more general way, that can
> > accomodate all kind o= f message exchange initiated by the HA and all king
> > of securi= ty and so on.
> >
> > I understand that your preference = is that the generic notiication
> > emssage should be able to acc= omodate any information exchange initiated
> > by the HA, is that= correct?
>
> No, I think I've still not quite managed to get = across what I'm trying
> to say. I'm not advocating any specific pro= perty of the generic notification
> mechanism, except that it should = be generic. I'm advocating that it should
> (in addition to being so= mewhat generic) be *useful* for the use case (or
> cases) we know abo= ut today. More below.
>
> > I am perfectly ok with any of = these or other options. My only point is
> > that the WG should d= efine what the scope of the generic notification is
> >
> &= gt;>> My question is then when to use the generic notification (with = the MH
> >>> type assigned to the generic notification) and= when to use a new MH
> >>> type, makes sese now or am i st= ill missing something?
> >> No, I think I got you now. But to = me that would mean that if you have to
> >> use a new MH type b= ecause the generic notification mechanism won't work,
> >> then= you have failed to define the generic notification mechanism
> >&= gt; appropriately.
> >>
> >> If you wish to use a n= ew MH type because the semantics is fundamentally
> >> differen= t than what's been envisaged for the generic notification, that's
> &= gt;> fine. I have a hard time seeing that applying to binding revocatio= n,
> >> though...
> >>
> > I would leave t= he binding revocation discussion out of this for now.
> > Once we= agreed on what the scope of the generic notification should be,
> &= gt; it should be fairly easy to understand if the binding revocation should=
> > use it or not i guess
>
> No no no. This is th= e point. We can define a beautiful mechanism
> which could be useles= s, or only useful for things which isn't really
> needed by anybody. = I don't think that's what we should do, though.
>
> How many = specific examples do we have of proposed messages with real
> deploym= ent needs behind them?
>
> Discussing the properties of a mess= age mechanism out of context of the
> specific examples which we know= are needed today may lead to a beautiful
> but useless design. Disc= ussing the properties of the message mechanism
> in the context of kn= own use cases is vital, in order to get something with
> a reasonable= chance of actually being appropriate and useful. Divorcing
> the ge= neric notification mechanism from the most obvious potential use
> ca= se for the mechanism doesn't make sense to me.
>
>
> Re= gards,
>
> Henrik
>
> __________________________= _____________________
> MEXT mailing list
> MEXT@ietf.org
&g= t; https://www.ietf.org/mailman/listinfo/mext
= --_91dfc6f6-a074-4cbf-8089-fe6b7a7a13b8_-- --===============1012953970== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1012953970==-- From mext-bounces@ietf.org Thu May 29 09:33:05 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 674283A6B8A; Thu, 29 May 2008 09:33:05 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 838263A6B8E for ; Thu, 29 May 2008 09:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pz36fVXA8vhR for ; Thu, 29 May 2008 09:33:03 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 3874B3A6B8A for ; Thu, 29 May 2008 09:33:03 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m4TGWXQ08101; Thu, 29 May 2008 16:32:33 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 May 2008 11:32:31 -0500 Message-ID: In-Reply-To: <483ECF89.1040806@levkowetz.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Scope of generic notification Thread-Index: AcjBoxyYJLjdxc3CRLmBFdXitwBNagAAbr4g References: <483D5A50.1000208@it.uc3m.es> <483DF6B1.2070205@levkowetz.com> <483E90BF.9060909@it.uc3m.es> <483EACB2.8030105@levkowetz.com> <483EB1B0.7030302@it.uc3m.es> <483EB3FF.1090602@levkowetz.com> <483EBC71.70102@it.uc3m.es> <483ECF89.1040806@levkowetz.com> From: "Ahmad Muhanna" To: "Henrik Levkowetz" , "marcelo bagnulo braun" Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Henrik, Allow me to jump in to address some of your comments/concern. Regards, Ahmad > > > > > I understand that your preference is that the generic notiication > > emssage should be able to accomodate any information exchange > > initiated by the HA, is that correct? > > No, I think I've still not quite managed to get across what > I'm trying to say. I'm not advocating any specific property > of the generic notification mechanism, except that it should > be generic. I'm advocating that it should (in addition to > being somewhat generic) be *useful* for the use case (or > cases) we know about today. More below. [Ahmad] Until the scope of that generic mechanism is quite understood and documented, we need to move forward. As many people already mentioned, there is a sensitive 3GPP Rel-8 dependency on draft, http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocatio n-01.txt, I guess it is hard to believe that this work needs to be delayed until people define the specific properties of such generic mechanism. > > > I would leave the binding revocation discussion out of this > for now. > > Once we agreed on what the scope of the generic notification should > > be, it should be fairly easy to understand if the binding > revocation > > should use it or not i guess > > No no no. This is the point. We can define a beautiful > mechanism which could be useless, or only useful for things > which isn't really needed by anybody. I don't think that's > what we should do, though. > > How many specific examples do we have of proposed messages > with real deployment needs behind them? > > Discussing the properties of a message mechanism out of > context of the specific examples which we know are needed > today may lead to a beautiful but useless design. [Ahmad] That is why there is a defined scope for the Binding revocation which has been captured as a MEXT wg item and addressed by the draft-muhanna. Do you see any problem with the proposed mechanism or the way Revocation is defined and addressed in that draft? > Discussing > the properties of the message mechanism in the context of > known use cases is vital, in order to get something with a > reasonable chance of actually being appropriate and useful. [Ahmad] Hmmm... This is exactly the problem that this thread is trying to resolve with this "generic" notion. We have a well defined usecases for Binding Revocation that have been identified and addressed already by draft-muhanna. On the other hand, you seem to suggest that we need to define a mechanism that is "generic" but yet has an "unknown scope" which in addition can address other "unknown usecases" which could be defined in the future and share some semantics of such generic mechanism. Does that make any sense? > Divorcing the generic notification mechanism from the most > obvious potential use case for the mechanism doesn't make sense to me. > > > Regards, > > Henrik > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 29 11:13:30 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BA0C28C0DB; Thu, 29 May 2008 11:13:30 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52EBC28C0E5 for ; Thu, 29 May 2008 11:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFX0sIgAGFmR for ; Thu, 29 May 2008 11:13:28 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 3A4033A6B38 for ; Thu, 29 May 2008 11:13:28 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 May 2008 13:50:47 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Scope of generic notification Thread-Index: AcjBEDgZgRlbCE5CTeiqQpsxH7u57QAAJhIgAAhNLpAAIHcAUA== References: <483D5A50.1000208@it.uc3m.es> <483DD94A.6070705@it.uc3m.es> From: "Vijay Devarapalli" To: "Ahmad Muhanna" , "marcelo bagnulo braun" Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > > > > The generic notification draft should support all of > the following > > > > > > > > - A simple notification message which you just send and > > > forget about it. > > > > Does not affect the state of the binding cache > > > > - A notification message that requires an ack. You > > > re-transmit until you > > > > get an ack or when you timeout > > > > - A notification message that does affect the binding > cache state > > > > - Enable the use of IPsec protection for the notification > > message if > > > > required > > > > > > > so, are you saying that any new functionality that uses > > this type of > > > message exchange should use the generic notification and > > not a new MH? > > > > No. The generic notification message would support all of the above. > > Applications that make use of the generic notification > > message can decide whether they want an explicit > > acknowledgement (for example by setting the 'ack' flag) or > > IPsec protection (for example by having the SPD entries configured). > > [Ahmad] > Hmmm.. > How would all of the above be supported in a single shot? The current generic notification draft does support all of the above. > For example, how would this generic notification mechanism support the > first very simple usecase "A simple notification message > which you just > send and forget about it", for example, your prepaid balance > is $25.09. > which MAY NOT require IPsec protection while at the same time support > usecase 2 Which impact the BCE and require IPsec protection, > while both > use the same MH type? In this case, you are right. Even if one notification message requires IPsec protection, you would end up using IPsec protection on all notification messages. I don't necessarily see that as a bad thing, though. Vijay > > > >> Now, the next question then is when to use a new MH > > header and when > > > >> to use the generic notification. I think the generic > > notification > > > >> document needs to explicitly define its scope. > > > > > > > > I think we may have to go with case-by-case basis. It would > > > be hard to > > > > set the criteria now. > > > > > > > I find this hard to accept > > > I mean, how are going to decide later? based on what if we don't > > > define a criteria? It should be possible to at least provide some > > > guidance on this. I am not saying we can define an selection > > > algorithm, but some guidance must be provided imho > > > > > > In other words, i guess you do have some abstract gut > > feeling on when > > > to use one and when to use the other one. > > > > Right. > > > > > this basically relies on some > > > conception of what the scope of the generic notification is. > > > My proposal > > > is to try to make the excersise to state this ideas > > explicltly, so we > > > can all agree on this. > > > > Ok, I will bite. How about the following for the criteria? > > > > - The generic notification message can be used anytime you > > want to indicate/convey/modify something related to an > > existing session. Here I am assuming that a session > > corresponds to one instance of a binding cache entry for a > > particular mobile node. > > > > - The generic notification message can be used to trigger > > another node to setup a session. This would mean the trigger > > is sent to the recipient (mobile node or a MAG) to send a > > binding update (or a proxy binding > > update) and setup a session. > > [Ahmad] > On one hand, you said that "this should be addressed in a case-by-case > because it would be hard to set the criteria now". In other words, you > probably meant to say that it would be very difficult to capture the > scope of this generic notification mechanism and its > limitations at the > present time. On the other hand, you just presented this very generic > and broad scope that made me think it would be easier if you specify > what has been left out. What I mean, if you define for us what is not > included, we probably would understand what is included in this scope > and luckily would be able to interpret what > "indicate/convey/modify" and > their combinations mean. > > > > > Vijay > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 29 11:55:19 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 555C73A6895; Thu, 29 May 2008 11:55:19 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53C303A6778 for ; Thu, 29 May 2008 11:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.454 X-Spam-Level: X-Spam-Status: No, score=-3.454 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMJP0MPD5LMW for ; Thu, 29 May 2008 11:55:17 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id CF3B73A6AF2 for ; Thu, 29 May 2008 11:54:24 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [163.117.203.43])by smtp01.uc3m.es (Postfix) with ESMTP id 32E64689AE0; Thu, 29 May 2008 20:54:20 +0200 (CEST) Message-ID: <483EEFDA.3010502@it.uc3m.es> Date: Thu, 29 May 2008 20:03:06 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Henrik Levkowetz References: <483D5A50.1000208@it.uc3m.es> <483DF6B1.2070205@levkowetz.com> <483E90BF.9060909@it.uc3m.es> <483EACB2.8030105@levkowetz.com> <483EB1B0.7030302@it.uc3m.es> <483EB3FF.1090602@levkowetz.com> <483EBC71.70102@it.uc3m.es> <483ECF89.1040806@levkowetz.com> In-Reply-To: <483ECF89.1040806@levkowetz.com> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-2.6365 TC:1F TRN:12 TV:5.5.1026(15940.001) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Julien Laganier , mext@ietf.org Subject: [MEXT] Question: potential uses for generic notification (was Re: Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Henrik Levkowetz escribi=F3: > > How many specific examples do we have of proposed messages with real > deployment needs behind them? > Does anyone has some input on this question? Regards, marcelo _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 29 12:10:26 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B8F73A696A; Thu, 29 May 2008 12:10:26 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46EF53A699A for ; Thu, 29 May 2008 12:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5Fu0DZLlLwe for ; Thu, 29 May 2008 12:10:24 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 56E663A696A for ; Thu, 29 May 2008 12:10:24 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m4TJADs23589; Thu, 29 May 2008 19:10:14 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 May 2008 14:10:01 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Scope of generic notification Thread-Index: AcjBEDgZgRlbCE5CTeiqQpsxH7u57QAAJhIgAAhNLpAAIHcAUAACjy6w References: <483D5A50.1000208@it.uc3m.es> <483DD94A.6070705@it.uc3m.es> From: "Ahmad Muhanna" To: "Vijay Devarapalli" , "marcelo bagnulo braun" Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > > > > [Ahmad] > > Hmmm.. > > How would all of the above be supported in a single shot? > > The current generic notification draft does support all of the above. > > > For example, how would this generic notification mechanism > support the > > first very simple usecase "A simple notification message which you > > just send and forget about it", for example, your prepaid > balance is > > $25.09. > > which MAY NOT require IPsec protection while at the same > time support > > usecase 2 Which impact the BCE and require IPsec protection, while > > both use the same MH type? > > In this case, you are right. Even if one notification message > requires IPsec protection, you would end up using IPsec > protection on all notification messages. I don't necessarily > see that as a bad thing, though. [Ahmad] Thanks. But this is a gainst the basic concept of getting a broad and generic mechanism that is able to address all of the above. I disagree. This is a restriction that defeat the purpose of the notion of a generic mechanism that is flexible enough to satisfy all the different usecases needs. IPsec is good when it is required. > > Vijay > > > > > >> Now, the next question then is when to use a new MH > > > header and when > > > > >> to use the generic notification. I think the generic > > > notification > > > > >> document needs to explicitly define its scope. > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 29 12:37:43 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EC1A3A6B82; Thu, 29 May 2008 12:37:43 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27E943A68A5 for ; Thu, 29 May 2008 12:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBMpanCA2tFk for ; Thu, 29 May 2008 12:37:41 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 2518F3A684D for ; Thu, 29 May 2008 12:37:41 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 May 2008 15:37:36 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Scope of generic notification Thread-Index: AcjBEDgZgRlbCE5CTeiqQpsxH7u57QAAJhIgAAhNLpAAIHcAUAACjy6wAAE07MA= References: <483D5A50.1000208@it.uc3m.es> <483DD94A.6070705@it.uc3m.es> From: "Vijay Devarapalli" To: "Ahmad Muhanna" , "marcelo bagnulo braun" Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > Sent: Thursday, May 29, 2008 12:10 PM > To: Vijay Devarapalli; marcelo bagnulo braun > Cc: Julien Laganier; mext@ietf.org > Subject: RE: [MEXT] Scope of generic notification > > > > > > > [Ahmad] > > > Hmmm.. > > > How would all of the above be supported in a single shot? > > > > The current generic notification draft does support all of > the above. > > > > > For example, how would this generic notification mechanism > > support the > > > first very simple usecase "A simple notification message > which you > > > just send and forget about it", for example, your prepaid > > balance is > > > $25.09. > > > which MAY NOT require IPsec protection while at the same > > time support > > > usecase 2 Which impact the BCE and require IPsec > protection, while > > > both use the same MH type? > > > > In this case, you are right. Even if one notification message > > requires IPsec protection, you would end up using IPsec > > protection on all notification messages. I don't necessarily > > see that as a bad thing, though. > > [Ahmad] > Thanks. > > But this is a gainst the basic concept of getting a broad and generic > mechanism that is able to address all of the above. I > disagree. This is > a restriction that defeat the purpose of the notion of a generic > mechanism that is flexible enough to satisfy all the > different usecases > needs. IPsec is good when it is required. You are mixing up stuff. I was talking about the posibility of using the generic notification message with or without IPsec protection. The current draft supports both. You are talking about being able to send two separate generic notifications messages at the same time, one with and other without IPsec protection. I agree this is not possible currently, since we only have the MH Type as the selector, and not the subtype field in the generic notification message. Vijay _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 29 13:29:17 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC3B43A699A; Thu, 29 May 2008 13:29:17 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9C1A3A6BB1 for ; Thu, 29 May 2008 13:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFS5nxbUIvqu for ; Thu, 29 May 2008 13:29:15 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id BB9783A6BB0 for ; Thu, 29 May 2008 13:28:44 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m4TKSar18032; Thu, 29 May 2008 20:28:36 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 May 2008 15:28:04 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [MEXT] Scope of generic notification Thread-Index: AcjBEDgZgRlbCE5CTeiqQpsxH7u57QAAJhIgAAhNLpAAIHcAUAAFLeewAABH+YA= From: "Mohamed Khalil" To: , "Vijay Devarapalli" Cc: julien.IETF@laposte.net Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Vijay, Please se inline. Regards, Mohamed > > > For example, how would this generic notification mechanism > support the > > first very simple usecase "A simple notification message which you > > just send and forget about it", for example, your prepaid > balance is > > $25.09. > > which MAY NOT require IPsec protection while at the same > time support > > usecase 2 Which impact the BCE and require IPsec protection, while > > both use the same MH type? > > In this case, you are right. Even if one notification message > requires IPsec protection, you would end up using IPsec > protection on all notification messages. I don't necessarily > see that as a bad thing, though. > [MK] But this means that this generic mechanism is not flexible to allow simple notification message and notification message which impact the BCE to coexist when they have different IPsec requirements. > Vijay > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 29 13:32:56 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02D6A3A69E2; Thu, 29 May 2008 13:32:56 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E05A63A6895 for ; Thu, 29 May 2008 13:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q66Yk69gpo0K for ; Thu, 29 May 2008 13:32:52 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 9C8173A685C for ; Thu, 29 May 2008 13:32:52 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m4TKWWQ10393; Thu, 29 May 2008 20:32:32 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 May 2008 15:32:21 -0500 Message-ID: In-Reply-To: <483EEFDA.3010502@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Question: potential uses for generic notification (was Re: Scope of generic notification Thread-Index: AcjBvac0j4h79KPNTq20nTz/ExTJvAAASMsw References: <483D5A50.1000208@it.uc3m.es> <483DF6B1.2070205@levkowetz.com> <483E90BF.9060909@it.uc3m.es> <483EACB2.8030105@levkowetz.com> <483EB1B0.7030302@it.uc3m.es> <483EB3FF.1090602@levkowetz.com> <483EBC71.70102@it.uc3m.es> <483ECF89.1040806@levkowetz.com> <483EEFDA.3010502@it.uc3m.es> From: "Ahmad Muhanna" To: "marcelo bagnulo braun" , "Henrik Levkowetz" Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Question: potential uses for generic notification (was Re: Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > = > Henrik Levkowetz escribi=F3: > > > > How many specific examples do we have of proposed messages = > with real = > > deployment needs behind them? > > > Does anyone has some input on this question? Hi Marcello, Please let me address this question as follows: I am not sure if this question relevant to this scope definition. On one hand, we are not able to agree on the Generic Notification mechanism= scope because we do not have a full understanding of this mechanism to sta= rt with, nonetheless to come up with all of its usecases. On the other hand= , if people think that there is not many messages out there that require a = real deployment need, then why all of this debate about protection the MH t= ype field and why not allowing the use of different MH types as needed? Moreover, I would tend to say that the more appropriate question is to unde= rstand what is the real deployment need for such "Generic Notification Mech= anism" and if there is any dependency on it out there? That is probably a m= ore relevant question, IMO. Regards, Ahmad > = > Regards, marcelo > = > = > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 29 13:45:14 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AD8E3A6B99; Thu, 29 May 2008 13:45:14 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A5BD3A6BC7 for ; Thu, 29 May 2008 13:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xwtdc7uY5rYs for ; Thu, 29 May 2008 13:45:05 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id B54873A6BB2 for ; Thu, 29 May 2008 13:44:55 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m4TKijr20184; Thu, 29 May 2008 20:44:45 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 May 2008 15:44:40 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Scope of generic notification Thread-Index: AcjBEDgZgRlbCE5CTeiqQpsxH7u57QAAJhIgAAhNLpAAIHcAUAACjy6wAAE07MAAAibb0A== References: <483D5A50.1000208@it.uc3m.es> <483DD94A.6070705@it.uc3m.es> From: "Ahmad Muhanna" To: "Vijay Devarapalli" , "marcelo bagnulo braun" Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org > You are > talking about being able to send two separate generic > notifications messages at the same time, one with and other > without IPsec protection. I agree this is not possible > currently, since we only have the MH Type as the selector, > and not the subtype field in the generic notification message. [Ahmad] Okay. IMO, this is not a good thing and against the basic claim of having a mechanism that is being generic. But I guess we are not far a part, you categorized it as "that is not a bad thing:) > > Vijay > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 29 21:10:16 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC7E93A6C12; Thu, 29 May 2008 21:10:15 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A06A03A6C06 for ; Thu, 29 May 2008 21:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cg8LQSlI4Mjo for ; Thu, 29 May 2008 21:10:13 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 4A2483A6ACE for ; Thu, 29 May 2008 21:10:10 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id m4U4A34K009964; Fri, 30 May 2008 13:10:03 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb3) with ESMTP id m4U4A4B22512; Fri, 30 May 2008 13:10:04 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili07) with ESMTP id m4U49wX05501; Fri, 30 May 2008 13:09:59 +0900 (JST) Received: from NW-Sephiroth ([10.81.113.116]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 May 2008 12:08:52 +0800 Received: from NWSephiroth by NW-Sephiroth (PGP Universal service); Fri, 30 May 2008 12:08:49 +0800 X-PGP-Universal: processed; by NW-Sephiroth on Fri, 30 May 2008 12:08:49 +0800 From: "Benjamin Lim" To: "'marcelo bagnulo braun'" , References: <483D5A50.1000208@it.uc3m.es> Date: Fri, 30 May 2008 12:08:49 +0800 Message-ID: <008601c8c20a$dd06c8d0$7471510a@psl.local> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <483D5A50.1000208@it.uc3m.es> Thread-Index: AcjAxHUNz2m+0GCOS46HHYSKNfy/xwBRh5iQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 30 May 2008 04:08:52.0185 (UTC) FILETIME=[DEB3DC90:01C8C20A] Cc: 'Julien Laganier' Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi, My $0.02 take on this discussion. To me, the purpose of the generic notification draft seems to try to preserve the scarce resource of MH type we have (though I seriously do not think we have even utilized around 10% of the MH type, but preparing early is always a good thing) If that is the case, then the scope of the generic notification draft is very clear cut. To define a format to allow future notification messages to be extended into it. For example, +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Proto | Header Len | MH Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Notify type | Notify Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Message Data . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In this case, future notification messages would just use this template in generic notification to define their specific action. For example, binding revocation will define the notification type, length and whatever message data (BRI, BRA) for the use of revoking bindings. I believe a simple format like this should not take more than a month to get it into the standard tracks in order not to delay the current revocation draft (since there is an industrial dependency on this draft at the moment). Further, on the question posted below, > How many specific examples do we have of proposed messages with real > deployment needs behind them? > Does anyone has some input on this question? Offhand, one example I can think of is that operators might have preferences for a multi-interface MN to send its signaling message over specific interface base on the link condition at the HA. I.e. HA notifies MN to use 3G link to send all control messages (e.g. BU) as MN's WLAN link is currently unstable. Regards, Benjamin Lim > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of marcelo bagnulo braun > Sent: Wednesday, May 28, 2008 9:13 PM > To: mext@ietf.org > Cc: Julien Laganier > Subject: [MEXT] Scope of generic notification > > Hi all, > > In our new charter we have a new item on a generic > notification mechanism. > During discussion over the last weeks, it seems to me that > the WG needs to make a decision about what is the scope of > the generic notification > > In summary, we need to decide which is the scope of the > generic notification and what is the scope of the existing MH types. > Essentially, what need to be as clear as possible are the > criteria for using the generic notification and which is the > criteria for using a MH type. > > We would kindly ask the WG to comment on this, so we can make > a decision > > Next, i include some background information about how i see > this, but feel free to completely ignore it. > > I guess that one way to scope the generic notification, we > could first define what is the goal of the generic > notification. From Sri's draft, for instance, my > understanding is that the generic notification goal is to > allow a mean to provide asynchronous messages. (i am not sure > what asynchronous means in this context, but i assume that it > means not included in a BU/BA exchange??). > > If that is the case, i don't see why we need this, since we > can always use another mobility header and define new > messages to be exchanged. > From Vijay's email, i understand that one of the goals is to > save MH types, since they are a scarce resource. That seems > reasonable. > Raj mentioned that Generic notification is to be used for non > critical things. Other mentioned that this should only be > used for send and discard things. > > > Now, the next question then is when to use a new MH header > and when to use the generic notification. I think the generic > notification document needs to explicitly define its scope. > > I guess that the elements that should be taken into account > for the definition of the scope are the message exchange > supported by the generic notification, the security mode, > others?. In the message exchange, the question is whether the > generic notification is just a notification, a notification > plus an ACK, reliable delivery (i.e. > retransmission till the sender receives an ACK), or a more > complex message exchange i.e. more than one message > retransmitted in each direction. > > Now, one option would be to define the generic notification > so broad that it is a mere extension of the MH type, so that > we can encode more values in there, without much definition > of the message format. > > Another option would be to define a query/response message > format and scope the generic notification to this type of > simple interactions. > > A third option would be to define a reliable delivery, whith > tiemouts and retransmissions (slightly more complex than the > previous one) > > Other options that support more complex message exchange > could also be conceived. > > So, bottom line we need to clearly define the scope of the > generic notification and when to use MH types for extnesions. > This include the type of message exchange supported, the type > of information conveyed (critical or just infoormation), > security and so on. I think this is a high level disucssion > that the WG needs to have before we can move forward with the > generic notification and also with the binding revocation, > since once we define what is the scope of generic > notification and the MH type usage, we will be able to > conclude in which category the binding revocation falls. > > Regards, marcelo > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 29 21:30:03 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 339CD3A6BFA; Thu, 29 May 2008 21:30:03 -0700 (PDT) X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 008413A6BEE; Thu, 29 May 2008 21:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080530043002.008413A6BEE@core3.amsl.com> Date: Thu, 29 May 2008 21:30:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-monami6-multiplecoa-08.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Multiple Care-of Addresses Registration Author(s) : R. Wakikawa, et al. Filename : draft-ietf-monami6-multiplecoa-08.txt Pages : 44 Date : 2008-05-29 According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses, but only one, called the primary care-of address, that can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple accesses simultaneously, in which case the mobile node would be configured with multiple active IPv6 care-of addresses. This document proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses. The extensions proposed in this document can be used by Mobile Routers using the NEMO (Network Mobility) Basic Support protocol as well. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-monami6-multiplecoa-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-29212631.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --NextPart-- From mext-bounces@ietf.org Thu May 29 21:32:36 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91D8228C141; Thu, 29 May 2008 21:32:36 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E7373A67B4 for ; Thu, 29 May 2008 21:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuBoeH0stVYy for ; Thu, 29 May 2008 21:32:34 -0700 (PDT) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.188]) by core3.amsl.com (Postfix) with ESMTP id 440D428C0DC for ; Thu, 29 May 2008 21:32:34 -0700 (PDT) Received: by rn-out-0910.google.com with SMTP id m64so322744rnd.18 for ; Thu, 29 May 2008 21:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:content-type:mime-version:subject:date:references:x-mailer; bh=p97WaogMNEqG3QimsNmSoMTccdnvxSz9Idr0WQTSGmg=; b=SAkcyLxbRCdww1a6jRLrO/NQJTs/dJceHr3AL4UdI7gWJEtF86b0neacERWCmBu1nmwx4d7imUlheMuGT7IpAhbaeNDuqbx9N7d/BSdj3D8Iz9N2RIQYYeh1kRMgmvBwQhYTwrrULPQRnOAMefkkn32cHjQwpB0FFkm/FQkCV6U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:mime-version:subject:date:references:x-mailer; b=SsOdiDOh6eA066lOiq0SArt8x1k6+MOhZfLbAVY/zgGRR6ncHQZ+GOJN//iOpOWiWrYk1UnCbPUPxBZ/TBZg3SuISJviSZqrAeZPAhlXwgj8yTZhMcmng9Jl3ngEFPeVonclVKM+zZRnZMIsPKvyeBXMmP/148iv3cJNIdfdDP4= Received: by 10.142.77.11 with SMTP id z11mr1952896wfa.23.1212121950586; Thu, 29 May 2008 21:32:30 -0700 (PDT) Received: from 178-1.tmplife.jp.interop.net ( [45.99.1.178]) by mx.google.com with ESMTPS id 30sm3593476wfd.1.2008.05.29.21.32.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 29 May 2008 21:32:30 -0700 (PDT) Message-Id: From: Ryuji Wakikawa To: mext Content-Type: multipart/mixed; boundary=Apple-Mail-30--260977958 Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 30 May 2008 13:32:19 +0900 References: <20080530043002.008413A6BEE@core3.amsl.com> X-Mailer: Apple Mail (2.919.2) Subject: [MEXT] Fwd: I-D Action:draft-ietf-monami6-multiplecoa-08.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --Apple-Mail-30--260977958 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hello all, I submitted the new version. We fixed all the comments received during WGLC. thanks ryuji Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: 2008/5/30 13:30:01:JST > To: i-d-announce@ietf.org > Cc: mext@ietf.org > Subject: [MEXT] I-D Action:draft-ietf-monami6-multiplecoa-08.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Mobility EXTensions for IPv6 > Working Group of the IETF. > > > Title : Multiple Care-of Addresses Registration > Author(s) : R. Wakikawa, et al. > Filename : draft-ietf-monami6-multiplecoa-08.txt > Pages : 44 > Date : 2008-05-29 > > According to the current Mobile IPv6 specification, a mobile node may > have several care-of addresses, but only one, called the primary > care-of address, that can be registered with its home agent and the > correspondent nodes. However, for matters of cost, bandwidth, delay, > etc, it is useful for the mobile node to get Internet access through > multiple accesses simultaneously, in which case the mobile node would > be configured with multiple active IPv6 care-of addresses. This > document proposes extensions to the Mobile IPv6 protocol to register > and use multiple care-of addresses. The extensions proposed in this > document can be used by Mobile Routers using the NEMO (Network > Mobility) Basic Support protocol as well. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-08.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. --Apple-Mail-30--260977958 Content-Disposition: attachment; filename=mime-attachment Content-Type: message/external-body; x-unix-mode=0666; name="mime-attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2008-05-29212631.I-D@ietf.org>

--Apple-Mail-30--260977958 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext --Apple-Mail-30--260977958 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --Apple-Mail-30--260977958-- From mext-bounces@ietf.org Thu May 29 23:16:21 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A2F83A6D04; Thu, 29 May 2008 23:16:21 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 139FA3A6CEC for ; Thu, 29 May 2008 23:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.762 X-Spam-Level: X-Spam-Status: No, score=-3.762 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LceGmaKmLrIy for ; Thu, 29 May 2008 23:16:18 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 4E83628C10C for ; Thu, 29 May 2008 23:10:10 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (247.45.217.87.dynamic.jazztel.es [87.217.45.247])by smtp01.uc3m.es (Postfix) with ESMTP id ACB3068C65F; Fri, 30 May 2008 08:09:36 +0200 (CEST) Message-ID: <483F9A20.30903@it.uc3m.es> Date: Fri, 30 May 2008 08:09:36 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Vijay Devarapalli References: <483D5A50.1000208@it.uc3m.es> <483DD94A.6070705@it.uc3m.es> In-Reply-To: X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-10.8032 TC:1F TRN:48 TV:5.5.1026(15940.005) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Vijay Devarapalli escribi=F3: > = > > = >> -----Original Message----- >> From: Ahmad Muhanna [mailto:amuhanna@nortel.com] = >> Sent: Thursday, May 29, 2008 12:10 PM >> To: Vijay Devarapalli; marcelo bagnulo braun >> Cc: Julien Laganier; mext@ietf.org >> Subject: RE: [MEXT] Scope of generic notification >> >> = >>>> [Ahmad] >>>> Hmmm.. >>>> How would all of the above be supported in a single shot? >>>> = >>> The current generic notification draft does support all of = >>> = >> the above. >> = >>>> For example, how would this generic notification mechanism = >>>> = >>> support the = >>> = >>>> first very simple usecase "A simple notification message = >>>> = >> which you = >> = >>>> just send and forget about it", for example, your prepaid = >>>> = >>> balance is = >>> = >>>> $25.09. >>>> which MAY NOT require IPsec protection while at the same = >>>> = >>> time support = >>> = >>>> usecase 2 Which impact the BCE and require IPsec = >>>> = >> protection, while = >> = >>>> both use the same MH type? >>>> = >>> In this case, you are right. Even if one notification message = >>> requires IPsec protection, you would end up using IPsec = >>> protection on all notification messages. I don't necessarily = >>> see that as a bad thing, though. = >>> = >> [Ahmad] >> Thanks. >> >> But this is a gainst the basic concept of getting a broad and generic >> mechanism that is able to address all of the above. I = >> disagree. This is >> a restriction that defeat the purpose of the notion of a generic >> mechanism that is flexible enough to satisfy all the = >> different usecases >> needs. IPsec is good when it is required. >> = > > You are mixing up stuff. I was talking about the posibility of using the > generic notification message with or without IPsec protection. The > current draft supports both. You are talking about being able to send > two separate generic notifications messages at the same time, one with > and other without IPsec protection. I agree this is not possible > currently, since we only have the MH Type as the selector, and not the > subtype field in the generic notification message. = > = But, i think the scope of discussion is not apropriate. I mean, = limitations of exisitng drafts are not relevant, since we don't have a = WG document yet for none of the items, so, if we think there is some = functionality is needed, and if this functionality is possible, we will = certainly find people to write it down on a draft So, the discussion should not be about what existing draft support or = not, but what can be actually done in general So, for me the questions are: - would a generic notification mechanism need to send both IPSec = protected and non protected messages at the same time? - if yes, is it possible to build this? Regards, marcelo > Vijay > > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 29 23:16:39 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CED6B3A6870; Thu, 29 May 2008 23:16:39 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A7AB28C1B7 for ; Thu, 29 May 2008 23:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.762 X-Spam-Level: X-Spam-Status: No, score=-3.762 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbr6gFfKHzXI for ; Thu, 29 May 2008 23:16:31 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id AD1CC28C25D for ; Thu, 29 May 2008 23:12:30 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (247.45.217.87.dynamic.jazztel.es [87.217.45.247])by smtp01.uc3m.es (Postfix) with ESMTP id 51E1668B82E; Fri, 30 May 2008 08:12:28 +0200 (CEST) Message-ID: <483F9ACB.4010906@it.uc3m.es> Date: Fri, 30 May 2008 08:12:27 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Mohamed Khalil References: In-Reply-To: X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-6.6222 TC:1F TRN:31 TV:5.5.1026(15940.005) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: julien.IETF@laposte.net, mext@ietf.org Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Mohamed Khalil escribi=F3: > Hi Vijay, > > Please se inline. > > Regards, > Mohamed > = > > = >>> For example, how would this generic notification mechanism >>> = >> support the >> = >>> first very simple usecase "A simple notification message which you >>> just send and forget about it", for example, your prepaid = >>> = >> balance is >> = >>> $25.09. >>> which MAY NOT require IPsec protection while at the same >>> = >> time support >> = >>> usecase 2 Which impact the BCE and require IPsec protection, while >>> both use the same MH type? >>> = >> In this case, you are right. Even if one notification message >> requires IPsec protection, you would end up using IPsec = >> protection on all notification messages. I don't necessarily = >> see that as a bad thing, though. = >> >> = > > [MK] > But this means that this generic mechanism is not flexible to allow > simple notification message and notification message which impact the > BCE to coexist when they have different IPsec requirements. > = This is not obvious to me I understand that if IPsec protection is needed, it is a problem if it = is not provided But i don't see a problem in the other way around. I see it more as a = tradeoff. Maybe it would be possibl to define a mechanism that is = generic enough to support both, but it is likely to e more complex. = Avoiding using IPsec is another form of optimizations, since using IPSec = has costs. The question is whether this is worth it regards, marcelo > = >> Vijay >> >> = > > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Thu May 29 23:16:48 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D91728C1DC; Thu, 29 May 2008 23:16:48 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84F9428C1D7 for ; Thu, 29 May 2008 23:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.762 X-Spam-Level: X-Spam-Status: No, score=-3.762 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iz+N8JrmpYn2 for ; Thu, 29 May 2008 23:16:45 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 113373A6C92 for ; Thu, 29 May 2008 23:15:18 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (247.45.217.87.dynamic.jazztel.es [87.217.45.247])by smtp01.uc3m.es (Postfix) with ESMTP id F1B3668B6FC; Fri, 30 May 2008 08:15:16 +0200 (CEST) Message-ID: <483F9B73.3060707@it.uc3m.es> Date: Fri, 30 May 2008 08:15:15 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Ahmad Muhanna References: <483D5A50.1000208@it.uc3m.es> <483DF6B1.2070205@levkowetz.com> <483E90BF.9060909@it.uc3m.es> <483EACB2.8030105@levkowetz.com> <483EB1B0.7030302@it.uc3m.es> <483EB3FF.1090602@levkowetz.com> <483EBC71.70102@it.uc3m.es> <483ECF89.1040806@levkowetz.com> <483EEFDA.3010502@it.uc3m.es> In-Reply-To: X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-21.8292 TC:1F TRN:36 TV:5.5.1026(15940.005) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: mext@ietf.org, Henrik Levkowetz , Julien Laganier Subject: Re: [MEXT] Question: potential uses for generic notification (was Re: Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Ahmad, Ahmad Muhanna escribi=F3: >> Henrik Levkowetz escribi=F3: >> = >>> How many specific examples do we have of proposed messages = >>> = >> with real = >> = >>> deployment needs behind them? >>> >>> = >> Does anyone has some input on this question? >> = > > Hi Marcello, > Please let me address this question as follows: > > I am not sure if this question relevant to this scope definition. > > On one hand, we are not able to agree on the Generic Notification mechani= sm scope because we do not have a full understanding of this mechanism to s= tart with, nonetheless to come up with all of its usecases. On the other ha= nd, if people think that there is not many messages out there that require = a real deployment need, then why all of this debate about protection the MH= type field and why not allowing the use of different MH types as needed? > > Moreover, I would tend to say that the more appropriate question is to un= derstand what is the real deployment need for such "Generic Notification Me= chanism" and if there is any dependency on it out there? That is probably a= more relevant question, IMO. > > = i guess there is a need cause the WG has decided that we needed to work = on this. i would expect that people that have supported working on this has a = clear view on what this is needed for and what are the use cases. regards, marcelo > Regards, > Ahmad > > = >> Regards, marcelo >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> = > > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri May 30 01:58:37 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43FD03A6BDC; Fri, 30 May 2008 01:58:37 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5E143A688F for ; Fri, 30 May 2008 01:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ka6-dulcZLHm for ; Fri, 30 May 2008 01:58:36 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id 8F5663A6BDC for ; Fri, 30 May 2008 01:58:35 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so81068fga.41 for ; Fri, 30 May 2008 01:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=LExGA4uuUMdzyIKN3g/eeQD/Mw42SvQXqZdEVC0pVPY=; b=QmHJfBNST5fd+Uu6pFrfS2ZgkdMC5Ba4cbHnJ+B36OaTHC8i+oSqn7noKxlAUjjzmbIvqG2HMjDeI2Rb1MqPSJiyfsr5h+OIWHCpAnxXR/N1oK7SuMy/eBlkL7B4FHkmwSonxTU2g/QzWksX4+ZLNBbdY0wwn65VoNe0tjQZuio= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=pP0/1SkpIN4Yde5f0JTe9CC5OIeJXLOgMhy18a+QlCJFNYyI2iS4ygcZc/JY+uRv7jBsVcU2iTZzvSzu6VjP4neCO33LLEvxdvJLvIkCIFf0Yt6QcNfwPf0lewVY3eFgSBinxaH7CBOONhgXBSqW3DvFj12Hd7RKu3BzN3f3ZnY= Received: by 10.86.23.17 with SMTP id 17mr379507fgw.44.1212137911835; Fri, 30 May 2008 01:58:31 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id b17sm687751fka.6.2008.05.30.01.58.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 30 May 2008 01:58:30 -0700 (PDT) From: Julien Laganier To: "Ahmad Muhanna" Date: Fri, 30 May 2008 10:59:20 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <483D5A50.1000208@it.uc3m.es> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200805301059.23703.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Ahmad, On Thursday 29 May 2008, Ahmad Muhanna wrote: > > No. The generic notification message would support all of the > > above. Applications that make use of the generic notification > > message can decide whether they want an explicit > > acknowledgement (for example by setting the 'ack' flag) or > > IPsec protection (for example by having the SPD entries > > configured). > > [Ahmad] > Hmmm.. > How would all of the above be supported in a single shot? > For example, how would this generic notification mechanism support > the first very simple usecase "A simple notification message which > you just send and forget about it", for example, your prepaid balance > is $25.09. which MAY NOT require IPsec protection while at the same > time support usecase 2 Which impact the BCE and require IPsec > protection, while both use the same MH type? For this specific issue, a simple solution would be for the generic notification mechanism to use two MH types, one for which SPD requires IPsec, and one for which the SPD allows bypassing IPsec. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri May 30 05:48:57 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F54928C1D7; Fri, 30 May 2008 05:48:57 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69E6F28C1D6 for ; Fri, 30 May 2008 05:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.266 X-Spam-Level: X-Spam-Status: No, score=-6.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0q9ArGINObN9 for ; Fri, 30 May 2008 05:48:51 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 5ADE93A67DD for ; Fri, 30 May 2008 05:48:37 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m4UCmR813062; Fri, 30 May 2008 12:48:27 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 30 May 2008 07:48:22 -0500 Message-ID: In-Reply-To: <200805301059.23703.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Scope of generic notification Thread-Index: AcjCM1fYMOu4JZNaSouCK8KilFktVAAHzxSw References: <483D5A50.1000208@it.uc3m.es> <200805301059.23703.julien.IETF@laposte.net> From: "Ahmad Muhanna" To: "Julien Laganier" Cc: mext@ietf.org Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Julien, Please se inline. Regards, Ahmad > -----Original Message----- > From: julien laganier [mailto:julien.laganier@gmail.com] On > Behalf Of Julien Laganier > Sent: Friday, May 30, 2008 3:59 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: Vijay Devarapalli; marcelo bagnulo braun; mext@ietf.org > Subject: Re: [MEXT] Scope of generic notification > > Hello Ahmad, > > On Thursday 29 May 2008, Ahmad Muhanna wrote: > > > No. The generic notification message would support all of > the above. > > > Applications that make use of the generic notification > message can > > > decide whether they want an explicit acknowledgement (for > example by > > > setting the 'ack' flag) or IPsec protection (for example > by having > > > the SPD entries configured). > > > > [Ahmad] > > Hmmm.. > > How would all of the above be supported in a single shot? > > For example, how would this generic notification mechanism > support the > > first very simple usecase "A simple notification message which you > > just send and forget about it", for example, your prepaid > balance is > > $25.09. which MAY NOT require IPsec protection while at the > same time > > support usecase 2 Which impact the BCE and require IPsec > protection, > > while both use the same MH type? > > For this specific issue, a simple solution would be for the > generic notification mechanism to use two MH types, one for > which SPD requires IPsec, and one for which the SPD allows > bypassing IPsec. [Ahmad] I understand this to mean that the simple Notification message "No response is required" would have a MH type different than the more complex notification message "which may impact the BCE". That will do it. In this case, I assume that these two MH types messages can be handled separately. Thanks. > > --julien > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri May 30 06:17:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB8663A68EF; Fri, 30 May 2008 06:17:04 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E48B63A69EB for ; Fri, 30 May 2008 06:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.313 X-Spam-Level: X-Spam-Status: No, score=-6.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3x5RiAGOC20 for ; Fri, 30 May 2008 06:16:58 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id DD66728C1DC for ; Fri, 30 May 2008 06:15:46 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m4UDFKg25628; Fri, 30 May 2008 13:15:20 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 30 May 2008 08:15:19 -0500 Message-ID: In-Reply-To: <483F9B73.3060707@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Question: potential uses for generic notification (was Re: Scope of generic notification Thread-Index: AcjCHIvmIBgwLYo3Slya70qpEkKqaQAOW81Q References: <483D5A50.1000208@it.uc3m.es> <483DF6B1.2070205@levkowetz.com> <483E90BF.9060909@it.uc3m.es> <483EACB2.8030105@levkowetz.com> <483EB1B0.7030302@it.uc3m.es> <483EB3FF.1090602@levkowetz.com> <483EBC71.70102@it.uc3m.es> <483ECF89.1040806@levkowetz.com> <483EEFDA.3010502@it.uc3m.es> <483F9B73.3060707@it.uc3m.es> From: "Ahmad Muhanna" To: "marcelo bagnulo braun" Cc: mext@ietf.org, Henrik Levkowetz , Julien Laganier Subject: Re: [MEXT] Question: potential uses for generic notification (was Re: Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi marcelo, > = > Ahmad Muhanna escribi=F3: > >> Henrik Levkowetz escribi=F3: > >> = > >>> How many specific examples do we have of proposed messages > >>> = > >> with real > >> = > >>> deployment needs behind them? > >>> > >>> = > >> Does anyone has some input on this question? > >> = > > > > Hi Marcello, > > Please let me address this question as follows: > > > > I am not sure if this question relevant to this scope definition. > > > > On one hand, we are not able to agree on the Generic = > Notification mechanism scope because we do not have a full = > understanding of this mechanism to start with, nonetheless to = > come up with all of its usecases. On the other hand, if = > people think that there is not many messages out there that = > require a real deployment need, then why all of this debate = > about protection the MH type field and why not allowing the = > use of different MH types as needed? > > > > Moreover, I would tend to say that the more appropriate = > question is to understand what is the real deployment need = > for such "Generic Notification Mechanism" and if there is any = > dependency on it out there? That is probably a more relevant = > question, IMO. > > > > = > i guess there is a need cause the WG has decided that we = > needed to work on this. > = > i would expect that people that have supported working on = > this has a clear view on what this is needed for and what are = > the use cases. [Ahmad] I agree. Actually I am one of those who supported and still do support the generic n= otification message work item. At the time, my understanding and the unders= tanding of many others of the scope was what I mentioned earlier. A mechani= sm to communicate a simple event which does not immediately impact the stat= e of the BCE. It also was in the scope to allow the sender to request the r= eceiver for a response or an ack. > = > regards, marcelo > = > = > = > > Regards, > > Ahmad > > > > = > >> Regards, marcelo > >> > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > >> > >> = > > > > = > = > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri May 30 06:24:55 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 847E23A68F4; Fri, 30 May 2008 06:24:55 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45CCF3A69B1 for ; Fri, 30 May 2008 06:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-ukhDHDQ6bH for ; Fri, 30 May 2008 06:24:53 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 281F43A68F4 for ; Fri, 30 May 2008 06:24:52 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m4UDOig27257; Fri, 30 May 2008 13:24:44 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 30 May 2008 08:24:25 -0500 Message-ID: In-Reply-To: <483F9A20.30903@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Scope of generic notification Thread-Index: AcjCG9KfwS49A+/RT7uiwmXS0f67QgAO73gQ References: <483D5A50.1000208@it.uc3m.es> <483DD94A.6070705@it.uc3m.es> <483F9A20.30903@it.uc3m.es> From: "Ahmad Muhanna" To: "marcelo bagnulo braun" , "Vijay Devarapalli" Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcelo, > > But, i think the scope of discussion is not apropriate. I > mean, limitations of exisitng drafts are not relevant, since > we don't have a WG document yet for none of the items, so, if > we think there is some functionality is needed, and if this > functionality is possible, we will certainly find people to > write it down on a draft > > So, the discussion should not be about what existing draft > support or not, but what can be actually done in general > > So, for me the questions are: > - would a generic notification mechanism need to send both > IPSec protected and non protected messages at the same time? [Ahmad] Yes. I see this as a valid scenario. > - if yes, is it possible to build this? [Ahmad] The sky is the limit:) Yet, another selector to be standardized and defined to allow SPD IPsec to be configured and enforced using the subtype field. An unnecessary complication that, IMO, not needed. In other words, Is it worth the effort, I believe it is not. > > Regards, marcelo > > > Vijay > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri May 30 06:52:24 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 958C83A69A8; Fri, 30 May 2008 06:52:24 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D8DA3A69B3 for ; Fri, 30 May 2008 06:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.531 X-Spam-Level: X-Spam-Status: No, score=-3.531 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1S74I8fnOTn for ; Fri, 30 May 2008 06:52:22 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 4838E3A69A8 for ; Fri, 30 May 2008 06:52:21 -0700 (PDT) Received: from dummyhost24.it.uc3m.es (unknown [163.117.139.215])by smtp03.uc3m.es (Postfix) with ESMTP id C3F7A3CE2A2;Fri, 30 May 2008 15:52:19 +0200 (CEST) Message-ID: <48400693.3020302@it.uc3m.es> Date: Fri, 30 May 2008 15:52:19 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Ahmad Muhanna References: <483D5A50.1000208@it.uc3m.es> <483DF6B1.2070205@levkowetz.com> <483E90BF.9060909@it.uc3m.es> <483EACB2.8030105@levkowetz.com> <483EB1B0.7030302@it.uc3m.es> <483EB3FF.1090602@levkowetz.com> <483EBC71.70102@it.uc3m.es> <483ECF89.1040806@levkowetz.com> <483EEFDA.3010502@it.uc3m.es> <483F9B73.3060707@it.uc3m.es> In-Reply-To: X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-27.7602 TC:1F TRN:48 TV:5.5.1026(15940.006) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: mext@ietf.org, Henrik Levkowetz , Julien Laganier Subject: Re: [MEXT] Question: potential uses for generic notification (wasRe: Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Ahmad Muhanna escribi=F3: > Hi marcelo, > > = >> Ahmad Muhanna escribi=F3: >> = >>>> Henrik Levkowetz escribi=F3: >>>> = >>>> = >>>>> How many specific examples do we have of proposed messages >>>>> = >>>>> = >>>> with real >>>> = >>>> = >>>>> deployment needs behind them? >>>>> >>>>> = >>>>> = >>>> Does anyone has some input on this question? >>>> = >>>> = >>> Hi Marcello, >>> Please let me address this question as follows: >>> >>> I am not sure if this question relevant to this scope definition. >>> >>> On one hand, we are not able to agree on the Generic = >>> = >> Notification mechanism scope because we do not have a full = >> understanding of this mechanism to start with, nonetheless to = >> come up with all of its usecases. On the other hand, if = >> people think that there is not many messages out there that = >> require a real deployment need, then why all of this debate = >> about protection the MH type field and why not allowing the = >> use of different MH types as needed? >> = >>> Moreover, I would tend to say that the more appropriate = >>> = >> question is to understand what is the real deployment need = >> for such "Generic Notification Mechanism" and if there is any = >> dependency on it out there? That is probably a more relevant = >> question, IMO. >> = >>> = >>> = >> i guess there is a need cause the WG has decided that we = >> needed to work on this. >> >> i would expect that people that have supported working on = >> this has a clear view on what this is needed for and what are = >> the use cases. >> = > [Ahmad] > I agree. > > Actually I am one of those who supported and still do support the generic= notification message work item. At the time, my understanding and the unde= rstanding of many others of the scope was what I mentioned earlier. A mecha= nism to communicate a simple event which does not immediately impact the st= ate of the BCE. It also was in the scope to allow the sender to request the= receiver for a response or an ack. > > > = I think Henrik is asking for much more concrete use cases than this one, = i.e. what actual functionality you have in mind for this... people have = talked about notification about prepaid status and so on. I guess that = is what Henrik is asking for thanks, marcelo >> regards, marcelo >> >> >> >> = >>> Regards, >>> Ahmad >>> >>> = >>> = >>>> Regards, marcelo >>>> >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> = >>>> = >>> = >>> = >> = > > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri May 30 07:11:26 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B603A3A68F4; Fri, 30 May 2008 07:11:26 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 632E728C1C5 for ; Fri, 30 May 2008 07:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkjyJzfHQsdl for ; Fri, 30 May 2008 07:11:24 -0700 (PDT) Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) by core3.amsl.com (Postfix) with ESMTP id 9486328C15D for ; Fri, 30 May 2008 07:11:24 -0700 (PDT) Received: from smtp1.fc.hp.com (smtp.cnd.hp.com [15.15.136.127]) by g1t0027.austin.hp.com (Postfix) with ESMTP id A1DEB389F4; Fri, 30 May 2008 14:11:23 +0000 (UTC) Received: from wrx.zko.hp.com (wrx.zko.hp.com [16.116.96.52]) by smtp1.fc.hp.com (Postfix) with ESMTP id 6788B1FD128; Fri, 30 May 2008 14:05:45 +0000 (UTC) Message-ID: <48400B09.3010100@hp.com> Date: Fri, 30 May 2008 10:11:21 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Ahmad Muhanna References: <483D5A50.1000208@it.uc3m.es> <200805301059.23703.julien.IETF@laposte.net> In-Reply-To: Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Ahmad Muhanna wrote: >> For this specific issue, a simple solution would be for the >> generic notification mechanism to use two MH types, one for >> which SPD requires IPsec, and one for which the SPD allows >> bypassing IPsec. I was about to send the same response, using two MH types seems like a good solution to me. > [Ahmad] > > I understand this to mean that the simple Notification message "No > response is required" would have a MH type different than the more > complex notification message "which may impact the BCE". That will do > it. In this case, I assume that these two MH types messages can be > handled separately. I don't think we should restrict what you consider a simple notification message to one MH type or another. We can use the same sub-types in either message, but obviously some messages must use IPsec as you said. -Brian _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri May 30 07:31:12 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2D4A28C291; Fri, 30 May 2008 07:31:11 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DE7B28C0F9 for ; Fri, 30 May 2008 07:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJkA64wC2WeU for ; Fri, 30 May 2008 07:31:08 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id C9ED028C2A7 for ; Fri, 30 May 2008 07:25:29 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so141433fga.41 for ; Fri, 30 May 2008 07:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=ivTeXAi+7bI7mpIimSjJMsfsnxx9x9EdggCs7lv7Q/4=; b=GsQapinQsWIYjNk0jboTMmri7QgHVxSXoA5G23xTQB4bSzKxYDHNGWow4RoaXSRvc/SG0oHdwUsPUXG265vrGeoTaq1DkeS0yPqF6/B6HGwHTYQXak3LJ+A9nep7jc6tCR9k9VmD0bi3IqTFbnWT8WB6hnJGkqskIQnZpRT5enY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=fIzDgsStv2CKiB82kXeTmKUkMp28CQUqLjxq75/ONekCUpmTA+0sMFYpH/hiOmMMemsvyph8NQLgPDiVWFJ8wn0wee0zLT4bWfirrR+hQ7iffT7k6XCOCUpLuolLBOuAcd7HJTCp9hlyuLv+yh8FntFumgBjKYoelFEfQy9JcgY= Received: by 10.86.27.9 with SMTP id a9mr1662285fga.58.1212157526335; Fri, 30 May 2008 07:25:26 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id 31sm1686465fkt.2.2008.05.30.07.25.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 30 May 2008 07:25:25 -0700 (PDT) From: Julien Laganier To: "Ahmad Muhanna" Date: Fri, 30 May 2008 16:26:13 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <483D5A50.1000208@it.uc3m.es> <200805301059.23703.julien.IETF@laposte.net> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200805301626.16050.julien.IETF@laposte.net> Cc: mext@ietf.org Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hello Ahmad, On Friday 30 May 2008, Ahmad Muhanna wrote: > > For this specific issue, a simple solution would be for the > > generic notification mechanism to use two MH types, one for > > which SPD requires IPsec, and one for which the SPD allows > > bypassing IPsec. > > [Ahmad] > > I understand this to mean that the simple Notification message "No > response is required" would have a MH type different than the more > complex notification message "which may impact the BCE". That will do > it. In this case, I assume that these two MH types messages can be > handled separately. Just to make sure: what I meant is that differentiation between notification messages requiring IPsec and those who don't can be based on using two different MH types. As for differentiation between notification messages of type "No response is required" vs. "which may impact the BCE", that can be handled via the notification message subtype. Regards. --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri May 30 07:31:53 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C453228C1CF; Fri, 30 May 2008 07:31:53 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCABF3A69B1 for ; Fri, 30 May 2008 07:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.377 X-Spam-Level: X-Spam-Status: No, score=-6.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTkPX8b3yJcM for ; Fri, 30 May 2008 07:31:44 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 5733828C27A for ; Fri, 30 May 2008 07:30:03 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m4UETw800576; Fri, 30 May 2008 14:29:58 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 30 May 2008 09:29:48 -0500 Message-ID: In-Reply-To: <48400B09.3010100@hp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Scope of generic notification Thread-Index: AcjCXw5woCPr8KAvQ/KoOXyoufG1VwAAhKTw References: <483D5A50.1000208@it.uc3m.es> <200805301059.23703.julien.IETF@laposte.net> <48400B09.3010100@hp.com> From: "Ahmad Muhanna" To: "Brian Haley" Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Brian, > > Ahmad Muhanna wrote: > >> For this specific issue, a simple solution would be for > the generic > >> notification mechanism to use two MH types, one for which SPD > >> requires IPsec, and one for which the SPD allows bypassing IPsec. > > I was about to send the same response, using two MH types > seems like a good solution to me. > > > [Ahmad] > > > > I understand this to mean that the simple Notification message "No > > response is required" would have a MH type different than the more > > complex notification message "which may impact the BCE". > That will do > > it. In this case, I assume that these two MH types messages can be > > handled separately. > > I don't think we should restrict what you consider a simple > notification message to one MH type or another. We can use > the same sub-types in either message, but obviously some > messages must use IPsec as you said. [Ahmad] I was merely using that as an example. But I agree. Thanks. > > -Brian > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri May 30 07:35:26 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16A1228C1D6; Fri, 30 May 2008 07:35:26 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA7D83A69A2 for ; Fri, 30 May 2008 07:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWvgyR7pslJc for ; Fri, 30 May 2008 07:35:21 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id DB89328C1D6 for ; Fri, 30 May 2008 07:34:57 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m4UEYkg09809; Fri, 30 May 2008 14:34:46 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 30 May 2008 09:34:33 -0500 Message-ID: In-Reply-To: <200805301626.16050.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Scope of generic notification Thread-Index: AcjCYQU0l12ro3WeRw268jb+oatkOQAAPRbQ References: <483D5A50.1000208@it.uc3m.es> <200805301059.23703.julien.IETF@laposte.net> <200805301626.16050.julien.IETF@laposte.net> From: "Ahmad Muhanna" To: "Julien Laganier" Cc: mext@ietf.org Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Julien, > > Hello Ahmad, > > On Friday 30 May 2008, Ahmad Muhanna wrote: > > > For this specific issue, a simple solution would be for > the generic > > > notification mechanism to use two MH types, one for which SPD > > > requires IPsec, and one for which the SPD allows bypassing IPsec. > > > > [Ahmad] > > > > I understand this to mean that the simple Notification message "No > > response is required" would have a MH type different than the more > > complex notification message "which may impact the BCE". > That will do > > it. In this case, I assume that these two MH types messages can be > > handled separately. > > Just to make sure: what I meant is that differentiation > between notification messages requiring IPsec and those who > don't can be based on using two different MH types. As for > differentiation between notification messages of type "No > response is required" vs. "which may impact the BCE", that > can be handled via the notification message subtype. [Ahmad] Thanks for the clarification. Agreed. > > Regards. > > --julien > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri May 30 07:42:21 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FF323A69FE; Fri, 30 May 2008 07:42:21 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 647BB28C0F9 for ; Fri, 30 May 2008 07:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.417 X-Spam-Level: X-Spam-Status: No, score=-6.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGsfz56eS+Bv for ; Fri, 30 May 2008 07:42:19 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 4FED73A69A2 for ; Fri, 30 May 2008 07:42:18 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m4UEedU04725; Fri, 30 May 2008 14:40:39 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 30 May 2008 09:41:51 -0500 Message-ID: In-Reply-To: <48400693.3020302@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Question: potential uses for generic notification (wasRe: Scope of generic notification Thread-Index: AcjCXGfnNLNwo6dYS2CScPVS5fiGkAABiTvQ References: <483D5A50.1000208@it.uc3m.es> <483DF6B1.2070205@levkowetz.com> <483E90BF.9060909@it.uc3m.es> <483EACB2.8030105@levkowetz.com> <483EB1B0.7030302@it.uc3m.es> <483EB3FF.1090602@levkowetz.com> <483EBC71.70102@it.uc3m.es> <483ECF89.1040806@levkowetz.com> <483EEFDA.3010502@it.uc3m.es> <483F9B73.3060707@it.uc3m.es> <48400693.3020302@it.uc3m.es> From: "Ahmad Muhanna" To: "marcelo bagnulo braun" Cc: mext@ietf.org, Henrik Levkowetz , Julien Laganier Subject: Re: [MEXT] Question: potential uses for generic notification (wasRe: Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Marcelo, > >>> Hi Marcello, > >>> Please let me address this question as follows: > >>> > >>> I am not sure if this question relevant to this scope definition. > >>> > >>> On one hand, we are not able to agree on the Generic > >>> > >> Notification mechanism scope because we do not have a full > >> understanding of this mechanism to start with, nonetheless > to come up > >> with all of its usecases. On the other hand, if people think that > >> there is not many messages out there that require a real > deployment > >> need, then why all of this debate about protection the MH > type field > >> and why not allowing the use of different MH types as needed? > >> > >>> Moreover, I would tend to say that the more appropriate > >>> > >> question is to understand what is the real deployment need > for such > >> "Generic Notification Mechanism" and if there is any > dependency on it > >> out there? That is probably a more relevant question, IMO. > >> > >>> > >>> > >> i guess there is a need cause the WG has decided that we needed to > >> work on this. > >> > >> i would expect that people that have supported working on > this has a > >> clear view on what this is needed for and what are the use cases. > >> > > [Ahmad] > > I agree. > > > > Actually I am one of those who supported and still do > support the generic notification message work item. At the > time, my understanding and the understanding of many others > of the scope was what I mentioned earlier. A mechanism to > communicate a simple event which does not immediately impact > the state of the BCE. It also was in the scope to allow the > sender to request the receiver for a response or an ack. > > > > > > > I think Henrik is asking for much more concrete use cases > than this one, i.e. what actual functionality you have in > mind for this... people have talked about notification about > prepaid status and so on. I guess that is what Henrik is asking for [Ahmad] It may be not the best day for me to come up with usecases:) However, as you mentioned the prepaid was one of the usecases that we discussed. I am sure others can identify more usecases. > > thanks, marcelo > > > >> regards, marcelo > >> > >> > >> > >> > >>> Regards, > >>> Ahmad > >>> > >>> > >>> > >>>> Regards, marcelo > >>>> > >>>> > >>>> _______________________________________________ > >>>> MEXT mailing list > >>>> MEXT@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mext > >>>> > >>>> > >>>> > >>> > >>> > >> > > > > > > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri May 30 07:51:52 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4227B28C202; Fri, 30 May 2008 07:51:52 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 197B228C202 for ; Fri, 30 May 2008 07:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3ZoDKPH+R3g for ; Fri, 30 May 2008 07:51:50 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id B3DFB28C1FB for ; Fri, 30 May 2008 07:51:30 -0700 (PDT) Received: from dummyhost24.it.uc3m.es (unknown [163.117.139.215])by smtp02.uc3m.es (Postfix) with ESMTP id 8693E39E0AA;Fri, 30 May 2008 16:51:28 +0200 (CEST) Message-ID: <48401470.40706@it.uc3m.es> Date: Fri, 30 May 2008 16:51:28 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: mext@ietf.org, Julien Laganier , Ralph Droms Content-Type: multipart/mixed; boundary=------------090108070002090502090508 X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-13.8864 TC:1F TRN:40 TV:5.5.1026(15940.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This is a multi-part message in MIME format. --------------090108070002090502090508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, We would like to ask the WG what is their opinion about accepting draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD deliverable included in our charter. Please provide comments so we cna make some progress on this long overdue deliverable thanks, Julien and marcelo -------- Mensaje original -------- Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) De: Internet-Drafts@ietf.org Responder a: internet-drafts@ietf.org Para: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DHCPv6 Prefix Delegation for NEMO Author(s) : R. Droms, et al. Filename : draft-droms-mext-nemo-pd-00.txt Pages : 12 Date : 2008-05-30 One aspect of network mobility support is the assignment of a prefix or prefixes to a Mobile Router (MR) for use on the links in the Mobile Network. DHCPv6 prefix delegation can be used for this configuration task. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------090108070002090502090508 Content-Type: Message/External-body; name="draft-droms-mext-nemo-pd-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-droms-mext-nemo-pd-00.txt" Content-Type: text/plain Content-ID: <2008-05-30054232.I-D@ietf.org> --------------090108070002090502090508 Content-Type: text/plain; name="Parte del mensaje adjunto" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Parte del mensaje adjunto" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------090108070002090502090508 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --------------090108070002090502090508-- From mext-bounces@ietf.org Fri May 30 10:03:42 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7587328C1EC; Fri, 30 May 2008 10:03:42 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6E2528C1A2 for ; Fri, 30 May 2008 10:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZC3d2MmKky6 for ; Fri, 30 May 2008 10:03:40 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 7400228C1F8 for ; Fri, 30 May 2008 10:03:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,568,1204531200"; d="scan'208";a="51922545" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 30 May 2008 10:03:24 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m4UH3OU3008036; Fri, 30 May 2008 10:03:24 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4UH3OQ3012601; Fri, 30 May 2008 17:03:24 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 May 2008 10:03:24 -0700 Received: from sgundavewxp ([10.32.246.210]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 May 2008 10:03:23 -0700 From: "Sri Gundavelli" To: "'marcelo bagnulo braun'" , References: <483D5A50.1000208@it.uc3m.es> Date: Fri, 30 May 2008 10:03:23 -0700 Message-ID: <000401c8c277$11d556f0$d2f6200a@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjAxKhQr/hLVYZiQOiwJbRsi7U1EgBsLneA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <483D5A50.1000208@it.uc3m.es> X-OriginalArrivalTime: 30 May 2008 17:03:23.0493 (UTC) FILETIME=[11C2B950:01C8C277] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2656; t=1212167004; x=1213031004; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[MEXT]=20Scope=20of=20generic=20notific ation |Sender:=20; bh=9E31zIFInw3pVjAh/SjBy1/UAP5+L7VSsgFmNqU6M6w=; b=Zj4tv09bKLGKe0lmTpsFb7icB+vlamq0Fe9q/TGMICKRlCz05h1Yye7HQY 7RhmxzhC4VtKubmODZ85u9UbLQ8LhcHMxjV1BfBpRy4ARb692Pnv0GLD9AzX 23OIBlpwAW; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'Julien Laganier' Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Catching up on this thread bit late ... > > In our new charter we have a new item on a generic > notification mechanism. > During discussion over the last weeks, it seems to me that > the WG needs to > make a decision about what is the scope of the generic notification > > In summary, we need to decide which is the scope of the generic > notification and what is the scope of the existing MH types. > Essentially, what need to be as clear as possible are the criteria > for using the generic notification and which is the criteria for > using a MH type. > Hi Marcelo, What is the scope of a Generic Notification Message ? Any events exchanged by the mobility entities during a mobility session (after the session is setup and when there is a relation), Generic Notification message can be used for exchanging those events. What is the benefit ? If we define a common frame work, exchange semantics, transport, security, retransmissions in one place, all events merely use this mechanism and define the data want to exchange and specify the receiver action. Their work can focus on the application semantics and not on how the events are exchanged. Lets look at the impact of this on Firewall drafts. For each MH type, firewall filter def will change. If we keep this contained to Generic Notification draft, all the events related to a mobility session and exchanged during a session, can all use this framework and no change on that aspect. Lets look at the security considerations, now we need to define SPD and PAD entries for each MH type. We can avoid all of this, if the Revocation or other events, simply use this mechanism. SDO bodies like 3GPP can allocate on of the subtype from this numbering space and can focus on the application data and with out getting into the details of transport semantics. Mobile IPv4 has adopted Generic Notification draft and the general direction as I understand is to use this for new events. Bottom line, the scope of the Notification draft is - Exchange of events related to a mobility session and during a mobility session. - Use of new MH types for new events should be allowed, only if the Generic Notification draft is not sufficient or has limitations to support those event semantics. If there is a good reason, sure. In general this should be sufficient for all events. But, if some one desperately wants to use a new MH type for their event and for what ever reason, that's fine. Just that the document will bloat in size, it will have to address all the security, firewall and transport semantics. Sri _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri May 30 11:18:18 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 800CA3A6B21; Fri, 30 May 2008 11:18:18 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCF923A6A0F for ; Fri, 30 May 2008 11:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9eiCb99W25Q for ; Fri, 30 May 2008 11:18:15 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id C28A33A67DB for ; Fri, 30 May 2008 11:18:15 -0700 (PDT) Received: from 75.26.137.116 ([75.26.137.116]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Fri, 30 May 2008 18:18:10 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 30 May 2008 11:18:09 -0700 From: Vijay Devarapalli To: marcelo bagnulo braun , , Julien Laganier , Ralph Droms Message-ID: Thread-Topic: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? Thread-Index: AcjCgYNUrYyxbNhiqkyjNeB3eF9I0A== In-Reply-To: <48401470.40706@it.uc3m.es> Mime-version: 1.0 Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On 5/30/08 7:51 AM, "marcelo bagnulo braun" wrote: > Hi, > > We would like to ask the WG what is their opinion about accepting > draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD > deliverable included in our charter. > > Please provide comments so we cna make some progress on this long > overdue deliverable I think we should adopt the document as a WG document. We need a mechanism for delivering the mobile network prefix information dynamically to the mobile router. The only mechanism that we have today in RFC 3963 is manual configuration of the prefixes on the mobile router. Vijay > > thanks, Julien and marcelo > > -------- Mensaje original -------- > Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt > Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) > De: Internet-Drafts@ietf.org > Responder a: internet-drafts@ietf.org > Para: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : DHCPv6 Prefix Delegation for NEMO > Author(s) : R. Droms, et al. > Filename : draft-droms-mext-nemo-pd-00.txt > Pages : 12 > Date : 2008-05-30 > > One aspect of network mobility support is the assignment of a prefix > or prefixes to a Mobile Router (MR) for use on the links in the > Mobile Network. DHCPv6 prefix delegation can be used for this > configuration task. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri May 30 12:16:45 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F32A73A68E5; Fri, 30 May 2008 12:16:44 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B7AB3A67A4 for ; Fri, 30 May 2008 12:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.608 X-Spam-Level: X-Spam-Status: No, score=-3.608 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sr3JMA9akoe2 for ; Fri, 30 May 2008 12:16:43 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id D087B3A68E5 for ; Fri, 30 May 2008 12:16:41 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (unknown [163.117.203.43])by smtp01.uc3m.es (Postfix) with ESMTP id 7637C68E1E7; Fri, 30 May 2008 21:16:37 +0200 (CEST) Message-ID: <48405020.8030404@it.uc3m.es> Date: Fri, 30 May 2008 21:06:08 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Sri Gundavelli References: <483D5A50.1000208@it.uc3m.es> <000401c8c277$11d556f0$d2f6200a@amer.cisco.com> In-Reply-To: <000401c8c277$11d556f0$d2f6200a@amer.cisco.com> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-24.3255 TC:1F TRN:50 TV:5.5.1026(15942.001) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: 'Julien Laganier' , mext@ietf.org Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Sri, So, your view is that the generic notification should be as general as = possible and should be able to support reliable delivery, message = exchange from the HA and from the MN or for any other party involved, = with different type of security (IPSec protected and non IPSec = protected), for critical and for non critical things and so on? Regards, marcelo Sri Gundavelli escribi=F3: > Catching up on this thread bit late ... > = > > = >> In our new charter we have a new item on a generic = >> notification mechanism. = >> During discussion over the last weeks, it seems to me that = >> the WG needs to = >> make a decision about what is the scope of the generic notification >> >> In summary, we need to decide which is the scope of the generic >> notification and what is the scope of the existing MH types. >> Essentially, what need to be as clear as possible are the criteria >> for using the generic notification and which is the criteria for >> using a MH type. >> >> = > > Hi Marcelo, > > What is the scope of a Generic Notification Message ? > > Any events exchanged by the mobility entities during a mobility > session (after the session is setup and when there is a relation), > Generic Notification message can be used for exchanging those > events. > > What is the benefit ? If we define a common frame work, exchange > semantics, transport, security, retransmissions in one place, > all events merely use this mechanism and define the data want to > exchange and specify the receiver action. Their work can focus on > the application semantics and not on how the events are exchanged. > > Lets look at the impact of this on Firewall drafts. For each MH type, > firewall filter def will change. If we keep this contained to > Generic Notification draft, all the events related to a mobility > session and exchanged during a session, can all use this framework > and no change on that aspect. > > Lets look at the security considerations, now we need to define SPD > and PAD entries for each MH type. We can avoid all of this, if the > Revocation or other events, simply use this mechanism. > > SDO bodies like 3GPP can allocate on of the subtype from this = > numbering space and can focus on the application data and with out > getting into the details of transport semantics. > > Mobile IPv4 has adopted Generic Notification draft and the general > direction as I understand is to use this for new events. > > > Bottom line, the scope of the Notification draft is > > - Exchange of events related to a mobility session and during a > mobility session. = > > - Use of new MH types for new events should be allowed, only if the > Generic Notification draft is not sufficient or has limitations > to support those event semantics. If there is a good reason, sure. > > In general this should be sufficient for all events. But, if some > one desperately wants to use a new MH type for their event and for > what ever reason, that's fine. Just that the document will bloat in > size, it will have to address all the security, firewall and > transport semantics. > > > Sri > > > > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri May 30 13:23:07 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FDA13A6AA7; Fri, 30 May 2008 13:23:07 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62A2E3A6A54 for ; Fri, 30 May 2008 13:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIjsJkfowvxo for ; Fri, 30 May 2008 13:23:05 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id 545763A6C4A for ; Fri, 30 May 2008 13:22:53 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so6022ywj.49 for ; Fri, 30 May 2008 13:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=xyxrADPWFTRdo09sYcArfohYzbf3shyCGsGN+V0iShg=; b=E4eEcwgvhsUQePGCRd9tiFODO47ijsv+xRdk40zsdDJlYCxnzhInvYrBPHngLVrUd6Ij46YGsf7uo+RHqD2YJgaiIWhF+ACy6o4Za8nPjltpy5tNpV7CxrhAEnDT+T7aFUeQ1axHLVyxQFrBm/lGiugjsbhWM8PxaKjw4HC/zvQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Y5w5vmDHhPkrAUICgdSDeNwtTThMWskt3ifOHogfcVhc8spyP+vceABsi6dJtkIgEbi7fHxReN5O0UPJ31iunqDDacqBo3qcCtThy/Xinc9j8dowmmETijkjPff3AsN4n0lhmhwWPITVGLg/1FjLI39x7hf/RxAp082tnRPKSrk= Received: by 10.142.224.5 with SMTP id w5mr2323713wfg.215.1212178971116; Fri, 30 May 2008 13:22:51 -0700 (PDT) Received: by 10.142.240.12 with HTTP; Fri, 30 May 2008 13:22:50 -0700 (PDT) Message-ID: Date: Fri, 30 May 2008 21:22:50 +0100 From: "George Tsirtsis" To: "Vijay Devarapalli" , "marcelo bagnulo braun" , mext@ietf.org, "Julien Laganier" , "Ralph Droms" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <48401470.40706@it.uc3m.es> Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org I fully agree, we should adopt this document. Thanks George On 5/30/08, Vijay Devarapalli wrote: > On 5/30/08 7:51 AM, "marcelo bagnulo braun" wrote: > >> Hi, >> >> We would like to ask the WG what is their opinion about accepting >> draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD >> deliverable included in our charter. >> >> Please provide comments so we cna make some progress on this long >> overdue deliverable > > I think we should adopt the document as a WG document. We need a mechanism > for delivering the mobile network prefix information dynamically to the > mobile router. The only mechanism that we have today in RFC 3963 is manual > configuration of the prefixes on the mobile router. > > Vijay > >> >> thanks, Julien and marcelo >> >> -------- Mensaje original -------- >> Asunto: I-D Action:draft-droms-mext-nemo-pd-00.txt >> Fecha: Fri, 30 May 2008 05:45:01 -0700 (PDT) >> De: Internet-Drafts@ietf.org >> Responder a: internet-drafts@ietf.org >> Para: i-d-announce@ietf.org >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : DHCPv6 Prefix Delegation for NEMO >> Author(s) : R. Droms, et al. >> Filename : draft-droms-mext-nemo-pd-00.txt >> Pages : 12 >> Date : 2008-05-30 >> >> One aspect of network mobility support is the assignment of a prefix >> or prefixes to a Mobile Router (MR) for use on the links in the >> Mobile Network. DHCPv6 prefix delegation can be used for this >> configuration task. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-droms-mext-nemo-pd-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri May 30 13:38:40 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 322903A6A3D; Fri, 30 May 2008 13:38:40 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31D113A6A3D for ; Fri, 30 May 2008 13:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJdELNnYvHbw for ; Fri, 30 May 2008 13:38:38 -0700 (PDT) Received: from moog.chdir.org (unknown [IPv6:2002:58bf:2aa0:339b:f654:e10e:317f:e6fa]) by core3.amsl.com (Postfix) with ESMTP id AE8E63A69A1 for ; Fri, 30 May 2008 13:38:32 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1K2BMq-0006zy-1L; Fri, 30 May 2008 22:38:28 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: marcelo bagnulo braun References: <48401470.40706@it.uc3m.es> X-GnuPG-Key: 0x047A5026 X-Hashcash: 1:20:080530:julien.ietf@laposte.net::TL1HOP+ze7GsUiZ6:0000000000000000000000000000000000000002ot X-Hashcash: 1:20:080530:rdroms@cisco.com::oH/5uJewTL1mhNMe:00m81 X-Hashcash: 1:20:080530:marcelo@it.uc3m.es::OPRWrQLXneXtFUAl:00000000000000000000000000000000000000000002i8Y X-Hashcash: 1:20:080530:mext@ietf.org::MKZj1gDJkJJyIpvo:00007zua Date: Fri, 30 May 2008 22:38:17 +0200 In-Reply-To: <48401470.40706@it.uc3m.es> (marcelo bagnulo braun's message of "Fri, 30 May 2008 16:51:28 +0200") Message-ID: <87mym74jeu.fsf@natisbad.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1827735352==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1827735352== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable Hi, marcelo bagnulo braun writes: > We would like to ask the WG what is their opinion about accepting > draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD > deliverable included in our charter. > > Please provide comments so we cna make some progress on this long > overdue deliverable The document is short and easy to read (good point). On one side, I think that DHCPv6 makes some sense for Nemo PD for devices with some capabilities. On the other side, I wonder if it is not overkill (complexity, roundtrips, ...) for a use in small devices (phone?, PDA?) that will serve a single subnet with IPv6 stateless @ autoconf=20 In practice (as a HA and MR administrator), I'd like to be able to simply configure the prefixes for my MR in the HA configuration section for this MR and that those prefixes be sent to the MR during the initial binding if it ask for prefix(es). In a sense considering the an initial static configuration of a MR, switching to PD would mean: - changing a knob in the MR config to switch to prefix delegation - giving the prefix in the HA config, indicating PD for that MR i.e. no need for IDs, specific keys for auth, or additional relay and associated IPsec credentials config. I also have some comments on the "Security Considerations" section of the document. Don't hesitate to tell me if I missed sth or if it is out of scope. IMHO, this is a bit simplistic to delegate the security of NEMO PD to the Security Considerations sections of DHCPv6 and DHCPv6 PD documents. There are good chances that the environments where MR will operate may be a bit more hostile than those where more common routers are expected to operate (in operators or corporate networks).=20 Some initial thoughts: =2D What are the hypothesis behind 3315 and 3633 design decisions that do not hold anymore in MIPv6 environments (if any)? =2D "HAs and MRs SHOULD use DHCPv6 authentication": Why not a "MUST"? =2D how do the security mechanisms of both protocols interact? =2D In the simple mode (no relay), how will the use of multicast interact with IPsec protection of traffic if it is in place? =2D HMAC-MD5-based authentication method is the only one defined in 3315. Is it sufficient? =2D What is the impact of the assignment of new prefixes in a dynamic fashion w.r.t. the SPD and SADB or IKE daemons? How should that be handled. =2D ... Regards, a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIQGXAAlWVfAR6UCYRAhqOAJ92woLNYx1lnD0sXSKluWNLaDRF+gCfbNep dVwChtWXzIEeDYbDW/YFz8I= =pf5X -----END PGP SIGNATURE----- --=-=-=-- --===============1827735352== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1827735352==-- From mext-bounces@ietf.org Fri May 30 13:57:44 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED82E3A6AB4; Fri, 30 May 2008 13:57:43 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF7F03A6AB2 for ; Fri, 30 May 2008 13:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEyCDoI+nykn for ; Fri, 30 May 2008 13:57:41 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 8D5603A6C31 for ; Fri, 30 May 2008 13:56:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,568,1204531200"; d="scan'208";a="37516720" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 30 May 2008 13:56:23 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m4UKuNHp012428; Fri, 30 May 2008 13:56:23 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4UKuNvS012559; Fri, 30 May 2008 20:56:23 GMT Date: Fri, 30 May 2008 13:56:23 -0700 (PDT) From: Sri Gundavelli To: marcelo bagnulo braun In-Reply-To: <48405020.8030404@it.uc3m.es> Message-ID: References: <483D5A50.1000208@it.uc3m.es> <000401c8c277$11d556f0$d2f6200a@amer.cisco.com> <48405020.8030404@it.uc3m.es> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-654246144-1212180983=:2249" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3935; t=1212180983; x=1213044983; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20Scope=20of=20generic=20notific ation |Sender:=20; bh=YoMsDd9q4HTA1nTq75vLG6qDFqKHn2nwkRpOURE5KDQ=; b=LBGY6NQgk4/FO/sQdJP7yWsHibvlJ2PE0Pw3yaIxtwcftJJP/IBiIY7v4n pC2tynZ3K7/I2GKBx8R6diqKlGS3/fmqDXA8gV0fT0qtVqUG8mg+n/p4fscn F+N6Fb1Jan; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'Julien Laganier' , mext@ietf.org Subject: Re: [MEXT] Scope of generic notification X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-654246144-1212180983=:2249 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Marcelo, Yes. It should provide all the general semantics required for mobility entities to exchange events associated with the established mobility session. Regards Sri On Fri, 30 May 2008, marcelo bagnulo braun wrote: > Hi Sri, > > So, your view is that the generic notification should be as general as=20 > possible and should be able to support reliable delivery, message exchang= e=20 > from the HA and from the MN or for any other party involved, with differe= nt=20 > type of security (IPSec protected and non IPSec protected), for critical = and=20 > for non critical things and so on? > > Regards, marcelo > > > Sri Gundavelli escribi=F3: >> Catching up on this thread bit late ... >>=20 >> >>=20 >> > In our new charter we have a new item on a generic notification=20 >> > mechanism. During discussion over the last weeks, it seems to me that= =20 >> > the WG needs to make a decision about what is the scope of the generi= c=20 >> > notification >> >=20 >> > In summary, we need to decide which is the scope of the generic >> > notification and what is the scope of the existing MH types. >> > Essentially, what need to be as clear as possible are the criteria >> > for using the generic notification and which is the criteria for >> > using a MH type. >> >=20 >> >=20 >> >> Hi Marcelo, >> >> What is the scope of a Generic Notification Message ? >> >> Any events exchanged by the mobility entities during a mobility >> session (after the session is setup and when there is a relation), >> Generic Notification message can be used for exchanging those >> events. >> >> What is the benefit ? If we define a common frame work, exchange >> semantics, transport, security, retransmissions in one place, >> all events merely use this mechanism and define the data want to >> exchange and specify the receiver action. Their work can focus on >> the application semantics and not on how the events are exchanged. >> >> Lets look at the impact of this on Firewall drafts. For each MH type, >> firewall filter def will change. If we keep this contained to >> Generic Notification draft, all the events related to a mobility >> session and exchanged during a session, can all use this framework >> and no change on that aspect. >> >> Lets look at the security considerations, now we need to define SPD >> and PAD entries for each MH type. We can avoid all of this, if the >> Revocation or other events, simply use this mechanism. >> >> SDO bodies like 3GPP can allocate on of the subtype from this numbering >> space and can focus on the application data and with out >> getting into the details of transport semantics. >> >> Mobile IPv4 has adopted Generic Notification draft and the general >> direction as I understand is to use this for new events. >>=20 >> >> Bottom line, the scope of the Notification draft is >> >> - Exchange of events related to a mobility session and during a >> mobility session.=20 >> >> - Use of new MH types for new events should be allowed, only if the >> Generic Notification draft is not sufficient or has limitations >> to support those event semantics. If there is a good reason, sure. >> >> In general this should be sufficient for all events. But, if some >> one desperately wants to use a new MH type for their event and for >> what ever reason, that's fine. Just that the document will bloat in >> size, it will have to address all the security, firewall and >> transport semantics. >>=20 >> >> Sri >>=20 >>=20 >> >>=20 > > > > ---559023410-654246144-1212180983=:2249 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext ---559023410-654246144-1212180983=:2249-- From mext-bounces@ietf.org Fri May 30 14:45:37 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 798B53A6A7B; Fri, 30 May 2008 14:45:37 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8306A3A6A46 for ; Fri, 30 May 2008 14:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.762 X-Spam-Level: X-Spam-Status: No, score=-3.762 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+0r-DX-9IQf for ; Fri, 30 May 2008 14:45:33 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 9A3C23A6B0F for ; Fri, 30 May 2008 14:45:10 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (248.44.217.87.dynamic.jazztel.es [87.217.44.248])by smtp01.uc3m.es (Postfix) with ESMTP id 11E4068EF88; Fri, 30 May 2008 23:45:09 +0200 (CEST) Message-ID: <48407564.9000209@it.uc3m.es> Date: Fri, 30 May 2008 23:45:08 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Arnaud Ebalard References: <48401470.40706@it.uc3m.es> <87mym74jeu.fsf@natisbad.org> In-Reply-To: <87mym74jeu.fsf@natisbad.org> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-27.7482 TC:1F TRN:66 TV:5.5.1026(15942.002) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Hi Arnaud, thanks for the feedback Arnaud Ebalard escribi=F3: > Hi, > > marcelo bagnulo braun writes: > > = >> We would like to ask the WG what is their opinion about accepting >> draft-droms-mext-nemo-pd-00.txt as the WG document for the Nemo PD >> deliverable included in our charter. >> >> Please provide comments so we cna make some progress on this long >> overdue deliverable >> = > > The document is short and easy to read (good point). On one side, I > think that DHCPv6 makes some sense for Nemo PD for devices with some > capabilities. On the other side, I wonder if it is not overkill > (complexity, roundtrips, ...) for a use in small devices (phone?, PDA?) > that will serve a single subnet with IPv6 stateless @ autoconf = > > In practice (as a HA and MR administrator), I'd like to be able to > simply configure the prefixes for my MR in the HA configuration section > for this MR and that those prefixes be sent to the MR during the > initial binding if it ask for prefix(es). In a sense considering the > an initial static configuration of a MR, switching to PD would mean: > > - changing a knob in the MR config to switch to prefix delegation > - giving the prefix in the HA config, indicating PD for that MR > > i.e. no need for IDs, specific keys for auth, or additional relay and > associated IPsec credentials config. > > = I am not sure what you mean hre. Are you suggesting any additional = changes in the document? Or are you proposing using a different = mechanism other than dhcp for this? If it is the first one, please comment how to do this. If it is the second one, there is consensus in the WG (decided in the = last meeting and confirmed in the ml) that we are using dhcp for this, = so pleas do not go into this disucssion again > I also have some comments on the "Security Considerations" section of > the document. Don't hesitate to tell me if I missed sth or if it is out > of scope. > > IMHO, this is a bit simplistic to delegate the security of NEMO PD to > the Security Considerations sections of DHCPv6 and DHCPv6 PD documents. > There are good chances that the environments where MR will operate may > be a bit more hostile than those where more common routers are expected > to operate (in operators or corporate networks). = > > Some initial thoughts: > > - What are the hypothesis behind 3315 and 3633 design decisions that do > not hold anymore in MIPv6 environments (if any)? > - "HAs and MRs SHOULD use DHCPv6 authentication": Why not a "MUST"? > - how do the security mechanisms of both protocols interact? > - In the simple mode (no relay), how will the use of multicast interact > with IPsec protection of traffic if it is in place? > - HMAC-MD5-based authentication method is the only one defined in > 3315. Is it sufficient? > - What is the impact of the assignment of new prefixes in a dynamic > fashion w.r.t. the SPD and SADB or IKE daemons? How should that be > handled. > - ... > > = This should be discussed, since the security was one of the points that = needed more work and that the authors tried to address in thei document Regards, marcelo > Regards, > > a+ > > = _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Fri May 30 15:13:51 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64F463A6A96; Fri, 30 May 2008 15:13:51 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 545B93A6AB4 for ; Fri, 30 May 2008 15:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8FEK+0XMXih for ; Fri, 30 May 2008 15:13:49 -0700 (PDT) Received: from web84303.mail.re1.yahoo.com (web84303.mail.re1.yahoo.com [69.147.74.182]) by core3.amsl.com (Postfix) with SMTP id C4F613A6A78 for ; Fri, 30 May 2008 15:13:48 -0700 (PDT) Received: (qmail 3819 invoked by uid 60001); 30 May 2008 22:13:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=NEyCVrOMO4c6m3nSE/E1J9WRFIS81OOc0hsSgm+8etJE/ba+VZy4ejA0N6j7MS5ne72Xf8A84CNLodRdoUUvGxKdVqK6DxzycZKOcXZb6RAw71DfVxVcmIOXO4kO0/cqY2d80cq4Vcl/zsV91ptFo5ml9hjdbHnpccWk6wKQBGQ=; X-YMail-OSG: .i9iUP0VM1nHiKpCoaOLmQgYg2GALGjYsF9EVRKQUZUqsy4ieLmZrMIc1Q0LzYPX3yvF1myGkpqEdy6fcWPIHek7w2rmF9sVGomp07Y8NoyCz0C6NVjc_nz2tvM- Received: from [206.16.17.212] by web84303.mail.re1.yahoo.com via HTTP; Fri, 30 May 2008 15:13:47 PDT X-Mailer: YahooMailRC/975.41 YahooMailWebService/0.7.185 Date: Fri, 30 May 2008 15:13:47 -0700 (PDT) From: Behcet Sarikaya To: marcelo bagnulo braun , Arnaud Ebalard MIME-Version: 1.0 Message-ID: <744491.3565.qm@web84303.mail.re1.yahoo.com> Cc: mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1607039075==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============1607039075== Content-Type: multipart/alternative; boundary="0-687162937-1212185627=:3565" --0-687162937-1212185627=:3565 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Please see inline.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A----- Original Message= ----=0AFrom: marcelo bagnulo braun =0ATo: Arnaud Ebala= rd =0ACc: Julien Laganier ; mex= t@ietf.org=0ASent: Friday, May 30, 2008 4:45:08 PM=0ASubject: Re: [MEXT] Ad= option of draft-droms-mext-nemo-pd-00.txt?=0A=0AHi Arnaud,=0A=0Athanks for = the feedback=0A=0AArnaud Ebalard escribi=F3:=0A> Hi,=0A>=0A> marcelo bagnul= o braun writes:=0A>=0A> =0A>> We would like to ask th= e WG what is their opinion about accepting=0A>> draft-droms-mext-nemo-pd-00= .txt as the WG document for the Nemo PD=0A>> deliverable included in our ch= arter.=0A>>=0A>> Please provide comments so we cna make some progress on th= is long=0A>> overdue deliverable=0A>> =0A>=0A> The document is short and= easy to read (good point). On one side, I=0A> think that DHCPv6 makes some= sense for Nemo PD for devices with some=0A> capabilities. On the other sid= e, I wonder if it is not overkill=0A> (complexity, roundtrips, ...) for a u= se in small devices (phone?, PDA?)=0A> that will serve a single subnet with= IPv6 stateless @ autoconf =0A>=0A> In practice (as a HA and MR administrat= or), I'd like to be able to=0A> simply configure the prefixes for my MR in = the HA configuration section=0A> for this MR and that those prefixes be sen= t to the MR during the=0A> initial binding if it ask for prefix(es). In a s= ense considering the=0A> an initial static configuration of a MR, switching= to PD would mean:=0A>=0A> - changing a knob in the MR config to switch t= o prefix delegation=0A> - giving the prefix in the HA config, indicating = PD for that MR=0A>=0A> i.e. no need for IDs, specific keys for auth, or add= itional relay and=0A> associated IPsec credentials config.=0A=0AI think thi= s is a good point, we should not hurry up a solution just because it was lo= ng overdue.=0AI have the same concern. Instead of MR, HA could be a better = place for DHCP PD. =0Ahttp://tools.ietf.org/id/draft-sarikaya-mext-prefix-d= elegation-00.txt explains this and it is a much simpler document.=0A=0A>=0A= > =0AI am not sure what you mean hre. Are you suggesting any additional = =0Achanges in the document? Or are you proposing using a different =0Amecha= nism other than dhcp for this?=0A=0AIf it is the first one, please comment = how to do this.=0A=0AIf it is the second one, there is consensus in the WG = (decided in the =0Alast meeting and confirmed in the ml) that we are using = dhcp for this, =0Aso pleas do not go into this disucssion again=0A=0A> I al= so have some comments on the "Security Considerations" section of=0A> the d= ocument. Don't hesitate to tell me if I missed sth or if it is out=0A> of s= cope.=0A>=0A> IMHO, this is a bit simplistic to delegate the security of NE= MO PD to=0A> the Security Considerations sections of DHCPv6 and DHCPv6 PD d= ocuments.=0A> There are good chances that the environments where MR will op= erate may=0A> be a bit more hostile than those where more common routers ar= e expected=0A> to operate (in operators or corporate networks). =0A>=0A> So= me initial thoughts:=0A>=0A> - What are the hypothesis behind 3315 and 3633= design decisions that do=0A> not hold anymore in MIPv6 environments (if = any)?=0A> - "HAs and MRs SHOULD use DHCPv6 authentication": Why not a "MUST= "?=0A> - how do the security mechanisms of both protocols interact?=0A> - I= n the simple mode (no relay), how will the use of multicast interact=0A> = with IPsec protection of traffic if it is in place?=0A> - HMAC-MD5-based au= thentication method is the only one defined in=0A> 3315. Is it sufficient= ?=0A> - What is the impact of the assignment of new prefixes in a dynamic= =0A> fashion w.r.t. the SPD and SADB or IKE daemons? How should that be= =0A> handled.=0A> - ...=0A>=0A> =0AThis should be discussed, since the s= ecurity was one of the points that =0Aneeded more work and that the authors= tried to address in thei document=0A=0A=0ARegards, marcelo=0A=0A> Regards,= =0A>=0A> a+=0A>=0A> =0A=0A_______________________________________________= =0AMEXT mailing list=0AMEXT@ietf.org=0Ahttps://www.ietf.org/mailman/listinf= o/mext=0A --0-687162937-1212185627=:3565 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Please see inline.

Regards,

Behcet
----- Original Message ----
From: marcelo bagnulo braun <ma= rcelo@it.uc3m.es>
To: Arnaud Ebalard <arno@natisbad.org>
Cc:= Julien Laganier <julien.IETF@laposte.net>; mext@ietf.org
Sent: Fr= iday, May 30, 2008 4:45:08 PM
Subject: Re: [MEXT] Adoption of draft-drom= s-mext-nemo-pd-00.txt?

=0AHi Arnaud,

thanks for the feedback<= br>
Arnaud Ebalard escribi=F3:
> Hi,
>
> marcelo bagnu= lo braun <marcelo@it.uc3m.es> writes:
>
>  >> We would like to ask the WG what is their opinion about accepting=
>> draft-droms-mext-nemo-pd-00.txt as the WG document for the Nem= o PD
>> deliverable included in our charter.
>>
>&g= t; Please provide comments so we cna make some progress on this long
>= ;> overdue deliverable
>>   
>
> The do= cument is short and easy to read (good point). On one side, I
> think= that DHCPv6 makes some sense for Nemo PD for devices with some
> cap= abilities. On the other side, I wonder if it is not overkill
> (compl= exity, roundtrips, ...) for a use in small devices (phone?, PDA?)
> t= hat will serve a single subnet with IPv6 stateless @ autoconf
>
> In practice (as a HA and M= R administrator), I'd like to be able to
> simply configure the prefi= xes for my MR in the HA configuration section
> for this MR and that = those prefixes be sent to the MR during the
> initial binding if it a= sk for prefix(es). In a sense considering the
> an initial static con= figuration of a MR, switching to PD would mean:
>
>  - ch= anging a knob in the MR config to switch to prefix delegation
> = - giving the prefix in the HA config, indicating PD for that MR
>> i.e. no need for IDs, specific keys for auth, or additional relay an= d
> associated IPsec credentials config.

I think this is a good point, we should not hurry up a soluti= on just because it was long overdue.
I have the same concern. Instead of= MR, HA could be a better place for DHCP PD.
http://tools.ietf.org/id/draft-sarikaya-mext-prefix-delegation-00.txt = explains this and it is a much simpler document.

>
>=  
I am not sure what you mean hre. Are you suggesting any additio= nal
changes in the document? Or are you proposing using a different mechanism other than dhcp for this?

If it is the first one, please = comment how to do this.

If it is the second one, there is consensus = in the WG (decided in the
last meeting and confirmed in the ml) that we= are using dhcp for this,
so pleas do not go into this disucssion again=

> I also have some comments on the "Security Considerations" sec= tion of
> the document. Don't hesitate to tell me if I missed sth or = if it is out
> of scope.
>
> IMHO, this is a bit simplist= ic to delegate the security of NEMO PD to
> the Security Consideratio= ns sections of DHCPv6 and DHCPv6 PD documents.
> There are good chances that the environments where MR will operate may
> be a = bit more hostile than those where more common routers are expected
> = to operate (in operators or corporate networks).
>
> Some init= ial thoughts:
>
> - What are the hypothesis behind 3315 and 363= 3 design decisions that do
>  not hold anymore in MIPv6 environ= ments (if any)?
> - "HAs and MRs SHOULD use DHCPv6 authentication": W= hy not a "MUST"?
> - how do the security mechanisms of both protocols= interact?
> - In the simple mode (no relay), how will the use of mul= ticast interact
>  with IPsec protection of traffic if it is in= place?
> - HMAC-MD5-based authentication method is the only one defi= ned in
>  3315. Is it sufficient?
> - What is the impact = of the assignment of new prefixes in a dynamic
>  fashion w.r.t= . the SPD and SADB or IKE daemons? How should that be
> =20 handled.
> - ...
>
> 
This should be discussed= , since the security was one of the points that
needed more work and th= at the authors tried to address in thei document


Regards, marcel= o

> Regards,
>
> a+
>
> 

__= _____________________________________________
MEXT mailing list
MEXT@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/mext
--0-687162937-1212185627=:3565-- --===============1607039075== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============1607039075==-- From mext-bounces@ietf.org Fri May 30 16:48:04 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B65B13A6C53; Fri, 30 May 2008 16:48:04 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 220E93A6C42 for ; Fri, 30 May 2008 16:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXT1uDDrj6mW for ; Fri, 30 May 2008 16:48:02 -0700 (PDT) Received: from moog.chdir.org (unknown [IPv6:2002:58bf:2aa0:339b:f654:e10e:317f:e6fa]) by core3.amsl.com (Postfix) with ESMTP id 60A783A6CD7 for ; Fri, 30 May 2008 16:47:36 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1K2EJm-0004Ib-2L; Sat, 31 May 2008 01:47:30 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: marcelo bagnulo braun References: <48401470.40706@it.uc3m.es> <87mym74jeu.fsf@natisbad.org> <48407564.9000209@it.uc3m.es> X-GnuPG-Key: 0x047A5026 X-Hashcash: 1:20:080530:mext@ietf.org::z6hgza73VdwHrX1L:00002Au7 X-Hashcash: 1:20:080530:marcelo@it.uc3m.es::plTTGWOQkQfQcI1S:00000000000000000000000000000000000000000005X23 X-Hashcash: 1:20:080530:julien.ietf@laposte.net::Y8MRrmFdfH48wDbq:0000000000000000000000000000000000000063db X-Hashcash: 1:20:080530:rdroms@cisco.com::vsRSUpZ8pYVBlQPu:07CGk Date: Sat, 31 May 2008 01:47:20 +0200 Message-ID: <87bq2n4anr.fsf@natisbad.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: Julien Laganier , mext@ietf.org Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0855935453==" Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org --===============0855935453== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable Hi Marcelo, marcelo bagnulo braun writes: >> In practice (as a HA and MR administrator), I'd like to be able to >> simply configure the prefixes for my MR in the HA configuration section >> for this MR and that those prefixes be sent to the MR during the >> initial binding if it ask for prefix(es). In a sense considering the >> an initial static configuration of a MR, switching to PD would mean: >> >> - changing a knob in the MR config to switch to prefix delegation >> - giving the prefix in the HA config, indicating PD for that MR >> >> i.e. no need for IDs, specific keys for auth, or additional relay and >> associated IPsec credentials config. >> >>=20=20=20 > I am not sure what you mean hre. Are you suggesting any additional > changes in the document? Not in that part of my first reply. > Or are you proposing using a different mechanism other than dhcp for > this? No, I do not propose another mechanism. I just give my feedback on the pros and cons of the proposal in term of coverage. To make it clear, I think that the proposal will cover the needs of big infrastructures. As it is probably a part of the audience, I think the document deserves to be a Working Group item.=20 That been said, it's not because I consider that the document deserves to be WG item for that part of the audience that I think it will provide a "one size fits all" solution for NEMO PD, for instance for very small devices like PDA or Phones. I was basically wondering if I will ever have to install and configure a DHCPv6 server with Relay and PD support on my Phone or PDA just for the purpose of getting a prefix from my HA. But considering what you write below (hiring DHCP for the job is the consensus), this will be the case.=20 > If it is the first one, please comment how to do this. > > If it is the second one, there is consensus in the WG (decided in the > last meeting and confirmed in the ml) that we are using dhcp for this, > so pleas do not go into this disucssion again ok. Sorry for the noise, then. Just keep my comments w.r.t. the Security Considerations section.=20 Regards, a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIQJIPAlWVfAR6UCYRAlYqAJwN3wzCDmlR9SHJRahHyzKEm6awcQCdHxhQ LluQEkkmIVzwcwlORwtGx7o= =p/T3 -----END PGP SIGNATURE----- --=-=-=-- --===============0855935453== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --===============0855935453==-- From mext-bounces@ietf.org Sat May 31 19:59:33 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7A083A6AC7; Sat, 31 May 2008 19:59:33 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0945B3A6AD0 for ; Sat, 31 May 2008 19:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+80KPsrtjOC for ; Sat, 31 May 2008 19:59:31 -0700 (PDT) Received: from nskntmtas03p.mx.bigpond.com (nskntmtas03p.mx.bigpond.com [61.9.168.143]) by core3.amsl.com (Postfix) with ESMTP id C6D913A6AC7 for ; Sat, 31 May 2008 19:59:29 -0700 (PDT) Received: from nskntotgx02p.mx.bigpond.com ([124.185.235.96]) by nskntmtas03p.mx.bigpond.com with ESMTP id <20080601025925.VIRL4463.nskntmtas03p.mx.bigpond.com@nskntotgx02p.mx.bigpond.com>; Sun, 1 Jun 2008 02:59:25 +0000 Received: from [192.168.0.204] (really [124.185.235.96]) by nskntotgx02p.mx.bigpond.com with ESMTP id <20080601025922.ORDM1995.nskntotgx02p.mx.bigpond.com@[192.168.0.204]>; Sun, 1 Jun 2008 02:59:22 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Sun, 01 Jun 2008 12:59:20 +1000 From: Hesham Soliman To: George Tsirtsis , "mext@ietf.org" Message-ID: Thread-Topic: [MEXT] I-D Action:draft-ietf-mext-nemo-v4traversal-03.txt Thread-Index: AcjDk3y2bKDhlhSHKUmmStoiJYAHXQ== In-Reply-To: Mime-version: 1.0 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150201.4842108D.0018,ss=1,fgs=0 Subject: Re: [MEXT] I-D Action:draft-ietf-mext-nemo-v4traversal-03.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org Thanks, will do that. I changes a lot of them in the revision before last but it seems there are some still there. Hesham On 29/05/08 7:46 PM, "George Tsirtsis" wrote: > Hesham, > > I noticed some typos which you can fix whenever convinient. > It looks like some initial letters have been omitted in several places e.g.: > Page 36: > " > Home Agent SPD-S: > > F local_address = home_agent_1 & > > remote_address = home_address_1 & > " > I think this F is an "IF" > and in page 37 > " The above should result in BU/BA messages with the following BU > received by the home agent. > > Pv4 header (src=V4ADDR, dst=HA_V4ADDR) > > UDP header (sport=Z, dport=DSMIPv6)" > > "Pv4" should be "IPv4" > > George > > 2008/5/25 : >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Mobility EXTensions for IPv6 Working Group >> of the IETF. >> >> >> Title : Mobile IPv6 Support for Dual Stack Hosts and Routers >> Author(s) : H. Soliman >> Filename : draft-ietf-mext-nemo-v4traversal-03.txt >> Pages : 48 >> Date : 2008-05-25 >> >> The current Mobile IPv6 and NEMO specifications support IPv6 only. >> This specification extends those standards to allow the registration >> of IPv4 addresses and prefixes, respectively, and the transport of >> both IPv4 and IPv6 packets over the tunnel to the home agent. This >> specification also allows the Mobile Node to roam over both IPv6 and >> IPv4, including the case where Network Address Translation is present >> on the path between the mobile node and its home agent. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-v4traversal-03.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From mext-bounces@ietf.org Sun Jun 1 00:51:03 2008 Return-Path: X-Original-To: nemo-archive@megatron.ietf.org Delivered-To: ietfarch-nemo-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E280928C109; Sun, 1 Jun 2008 00:51:03 -0700 (PDT) X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 271FC3A69A9 for ; Sun, 1 Jun 2008 00:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1poVw6IdnnF for ; Sun, 1 Jun 2008 00:51:01 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by core3.amsl.com (Postfix) with ESMTP id 0F8523A6972 for ; Sun, 1 Jun 2008 00:51:00 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so385217and.122 for ; Sun, 01 Jun 2008 00:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=wluqcMDWPCnMrkvGmTPr4OazBdk/nmFCGaKTU9Ron0k=; b=fHgrUASPY52Cpfn2ivHc6qJxGuqt9cBkJAbaPo6ILaizh5GsLiTYkjc7HEpKS8+FNrDdnWf4w46RmU/j487O8yLdKKB3VUJmtSt0lBSJ//eJ0qVpXMUXAM9SULu8fpFDbFRuwq8j6CY0TEmvhGNuPGQPdkJrP81NqNsrJwvIGKw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bgKLq10E3hVIS/8nLiSL7I8r2WETG+37KXWX+iWwGxhhK1O38xp+NXGAYhgti8zHcVgWDbbl2CEo0fxbW7IJNkxg7RLkbQ/OeyY5s5P95mWk4nlJFHvSIdNBVFMmF8HBJFwhOWXNXwSGpfWbTIkIzKDJG5pU6FvAgxxHE+CIJfk= Received: by 10.100.140.2 with SMTP id n2mr12519547and.95.1212306656764; Sun, 01 Jun 2008 00:50:56 -0700 (PDT) Received: by 10.100.131.18 with HTTP; Sun, 1 Jun 2008 00:50:56 -0700 (PDT) Message-ID: Date: Sun, 1 Jun 2008 08:50:56 +0100 From: "George Tsirtsis" To: "Arnaud Ebalard" In-Reply-To: <87bq2n4anr.fsf@natisbad.org> MIME-Version: 1.0 Content-Disposition: inline References: <48401470.40706@it.uc3m.es> <87mym74jeu.fsf@natisbad.org> <48407564.9000209@it.uc3m.es> <87bq2n4anr.fsf@natisbad.org> Cc: mext@ietf.org, Julien Laganier Subject: Re: [MEXT] Adoption of draft-droms-mext-nemo-pd-00.txt? X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mext-bounces@ietf.org Errors-To: mext-bounces@ietf.org On Sat, May 31, 2008 at 12:47 AM, Arnaud Ebalard wrote: > Hi Marcelo, > > marcelo bagnulo braun writes: > >>> In practice (as a HA and MR administrator), I'd like to be able to >>> simply configure the prefixes for my MR in the HA configuration section >>> for this MR and that those prefixes be sent to the MR during the >>> initial binding if it ask for prefix(es). In a sense considering the >>> an initial static configuration of a MR, switching to PD would mean: >>> >>> - changing a knob in the MR config to switch to prefix delegation >>> - giving the prefix in the HA config, indicating PD for that MR >>> >>> i.e. no need for IDs, specific keys for auth, or additional relay and >>> associated IPsec credentials config. >>> >>> >> I am not sure what you mean hre. Are you suggesting any additional >> changes in the document? > > Not in that part of my first reply. > >> Or are you proposing using a different mechanism other than dhcp for >> this? > > No, I do not propose another mechanism. I just give my feedback on the > pros and cons of the proposal in term of coverage. To make it clear, I > think that the proposal will cover the needs of big infrastructures. As > it is probably a part of the audience, I think the document deserves to > be a Working Group item. > > That been said, it's not because I consider that the document deserves > to be WG item for that part of the audience that I think it will provide > a "one size fits all" solution for NEMO PD, for instance for very small > devices like PDA or Phones. I was basically wondering if I will ever > have to install and configure a DHCPv6 server with Relay and PD support > on my Phone or PDA just for the purpose of getting a prefix from my > HA. But considering what you write below (hiring DHCP for the job is > the consensus), this will be the case. > Arnaud, This maybe simply a misunderstanding but draft-droms does not require you to do this. The Mobile Router, is a Requesting Router (RR) i.e., a DHCP-PD client. So no server functionality is required in you small devices. George _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext