From yuri@ismailov.eu Mon Feb 1 08:25:00 2010 Return-Path: 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 6D5CA28C1AA for ; Mon, 1 Feb 2010 08:25:00 -0800 (PST) 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 8OyEUa9RwDOX for ; Mon, 1 Feb 2010 08:24:59 -0800 (PST) Received: from mailout1.eurodns.com (mailout1.eurodns.com [80.92.77.12]) by core3.amsl.com (Postfix) with ESMTP id 146A63A6975 for ; Mon, 1 Feb 2010 08:24:55 -0800 (PST) Received: from [213.159.189.30] (unknown [213.159.189.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: yuri@ismailov.eu) by mailout1.eurodns.com (Postfix) with ESMTP id 31820576AF0; Mon, 1 Feb 2010 17:25:29 +0100 (CET) Message-ID: <4B67006D.3010006@ismailov.eu> Date: Mon, 01 Feb 2010 17:25:17 +0100 From: Yuri Ismailov User-Agent: Thunderbird 2.0.0.23 (X11/20091002) MIME-Version: 1.0 To: marcelo bagnulo braun References: <4B5EAB2A.9030404@it.uc3m.es> In-Reply-To: <4B5EAB2A.9030404@it.uc3m.es> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mext Subject: Re: [MEXT] WGLC for firewall 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: , X-List-Received-Date: Mon, 01 Feb 2010 16:25:00 -0000 Hi, I reviewed the draft draft-ietf-mext-firewall-admin-02. The document looks quite solid and addresses all important issues. However, there is one issue, in my opinion, which was left aside in the draft. I think that the section 6.2 should be completed with the recommendations about letting specific ICMPv4 error messages to pass through firewalls. This has to do with the path MTU discovery. Because this draft is concerned the firewall traversal, there is no need to talk about MTU tuning, however, I believe that firewall traversal is worth while mentioning. There is a reference to RFC 4890 at the end, which is concerned with ICMPv6 only. When using DSMIPv6 with NAT traversal, ICMPv4 error messages regarding MTU size could be sent as well. Thus the suggestion is to additionally refer the specifications RFC1191 and RFC1981, specifying path MTU discovery for IPv4 and IPv6 correspondingly. I suggest to add some text (see proposal below) at the end of the section 6.2, which specifically addresses data packets for DSMIPv6. Signaling packets probably not that important as MTU sizes will not be exceeded, or in case it will happen, the result will be anyway ICMPv4 error messages as signaling will be UDP encapsulated as well. Proposed text at the end of the section 6.2 When using DSMIPv6 with NAT traversal, the MTU sizes and correspondingly Maximum Segment Size (MSS) for TCP will have to be reduced due to the number of encapsulation headers in the data and signaling packets. This creates a need for path MTU discovery (RFC1191, RFC1981) to be supported in the infrastructure for visited networks and HA as well. As DSMIPv6 NAT traversal mechanism suggests using IPv4/UDP encapsulation of packets, the above mentioned path MTU discovery procedure may involve ICMPv4 "Destination Unreachable, fragmentation needed and DF set" (RFC792) message to be returned to the sender. This message may be sent by any node along the path including mobile node itself. In the case mobile node resides behind firewall, the firewall should let this type of packet (ICMP type 3, code 4) through, in order the messages could reach the sender. The same recommendation applies to the firewalls in mobile's node Home Network. Regards Yuri marcelo bagnulo braun wrote: > This is the WGLC for the two drafts related to firewall and MIPv6 i.e. > draft-ietf-mext-firewall-admin-02.txt and > draft-ietf-mext-firewall-vendor-02.txt. > > Please review the documents and send comments until Feb 15. > > For you convenience, the drafts can be found at: > > http://www.ietf.org/id/draft-ietf-mext-firewall-admin-02.txt > http://www.ietf.org/id/draft-ietf-mext-firewall-vendor-02.txt > > Regards, marcelo > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From suresh.krishnan@ericsson.com Mon Feb 1 13:06:27 2010 Return-Path: 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 4D0BD3A6874 for ; Mon, 1 Feb 2010 13:06:27 -0800 (PST) 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 6rnFCAvj72mm for ; Mon, 1 Feb 2010 13:06:26 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 1E45A3A69AE for ; Mon, 1 Feb 2010 13:06:26 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o11L85nR001943; Mon, 1 Feb 2010 15:08:05 -0600 Received: from [142.133.10.113] (147.117.20.212) by eusaamw0712.eamcs.ericsson.se (147.117.20.182) with Microsoft SMTP Server id 8.1.375.2; Mon, 1 Feb 2010 16:06:59 -0500 Message-ID: <4B674186.2050008@ericsson.com> Date: Mon, 1 Feb 2010 16:03:02 -0500 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Yuri Ismailov References: <4B5EAB2A.9030404@it.uc3m.es> <4B67006D.3010006@ismailov.eu> In-Reply-To: <4B67006D.3010006@ismailov.eu> Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Cc: mext Subject: Re: [MEXT] WGLC for firewall 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: , X-List-Received-Date: Mon, 01 Feb 2010 21:06:27 -0000 Hi Yuri, Thanks for your comments. Cheers Suresh On 10-02-01 11:25 AM, Yuri Ismailov wrote: > Hi, > I reviewed the draft draft-ietf-mext-firewall-admin-02. > The document looks quite solid and addresses all important issues. Sounds good. > > However, there is one issue, in my opinion, which was left aside in the > draft. > I think that the section 6.2 should be completed with the recommendations > about letting specific ICMPv4 error messages to pass through firewalls. You are right. We did not think about this as DSMIPv6 was a late addition to this document. It makes sense to add these recommendations. > This has > to do with the path MTU discovery. Because this draft is concerned the > firewall traversal, there is no need to talk about MTU tuning, however, > I believe that firewall traversal is worth while mentioning. > There is a reference to RFC 4890 at the end, which is concerned with > ICMPv6 only. > When using DSMIPv6 with NAT traversal, ICMPv4 error messages regarding > MTU size > could be sent as well. Thus the suggestion is to additionally refer the > specifications > RFC1191 and RFC1981, specifying path MTU discovery for IPv4 and IPv6 > correspondingly. OK. > > I suggest to add some text (see proposal below) at the end of the > section 6.2, which specifically addresses data packets for DSMIPv6. > Signaling packets probably not that important as MTU sizes will not be > exceeded, > or in case it will happen, the result will be anyway ICMPv4 error > messages as > signaling will be UDP encapsulated as well. > > Proposed text at the end of the section 6.2 > > When using DSMIPv6 with NAT traversal, the MTU sizes and correspondingly > Maximum > Segment Size (MSS) for TCP will have to be reduced due to the number > of encapsulation headers in the data and signaling packets. This creates > a need > for path MTU discovery (RFC1191, RFC1981) to be supported in the > infrastructure > for visited networks and HA as well. As DSMIPv6 NAT traversal mechanism > suggests > using IPv4/UDP encapsulation of packets, the above mentioned path MTU > discovery > procedure may involve ICMPv4 "Destination Unreachable, fragmentation > needed and DF set" > (RFC792) message to be returned to the sender. This message may be sent > by any node > along the path including mobile node itself. In the case mobile node > resides behind > firewall, the firewall should let this type of packet (ICMP type 3, code > 4) through, > in order the messages could reach the sender. The same recommendation > applies to the > firewalls in mobile's node Home Network. Looks good. Will add the text. Thanks Suresh From yuri@ismailov.eu Mon Feb 1 13:24:48 2010 Return-Path: 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 04FA63A6999 for ; Mon, 1 Feb 2010 13:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6] 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 A88bESAGZVXn for ; Mon, 1 Feb 2010 13:24:47 -0800 (PST) Received: from mailout1.eurodns.com (mailout1.eurodns.com [80.92.77.12]) by core3.amsl.com (Postfix) with ESMTP id E745F3A68B8 for ; Mon, 1 Feb 2010 13:24:46 -0800 (PST) Received: from [192.168.0.101] (c-349672d5.05-154-73746f3.cust.bredbandsbolaget.se [213.114.150.52]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: yuri@ismailov.eu) by mailout1.eurodns.com (Postfix) with ESMTP id 655D9576AC6; Mon, 1 Feb 2010 22:25:21 +0100 (CET) Message-ID: <4B674862.3060000@ismailov.eu> Date: Mon, 01 Feb 2010 22:32:18 +0100 From: Yuri Ismailov User-Agent: Thunderbird 2.0.0.23 (X11/20090927) MIME-Version: 1.0 To: Suresh Krishnan References: <4B5EAB2A.9030404@it.uc3m.es> <4B67006D.3010006@ismailov.eu> <4B674186.2050008@ericsson.com> In-Reply-To: <4B674186.2050008@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mext Subject: [MEXT] Draft Review 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: , X-List-Received-Date: Mon, 01 Feb 2010 21:24:48 -0000 Hi, After sending comment about path MTU I just thought that things could be more serious than that.This is not related to the draft for FW traversal, but I want to share my concerns here.with the group. Assume that infrastructure works as it should and path MTU discovery implemented and functional in all nodes. Firewalls are opened for necessary traffic to path through. However, when using DSMIPv6 with NAT traversal, the outer header contains source IP address, which is HA IPv4 address. Any intermediary node, in case of less MTU along the next hop will send ICMP Host Unreachable to the HA. Basically, the ICMP will never reach CN, which will keep sending packets with the same MTU, exceeding the required one. This has bad consequences. For example TCP connection will be established (SYN exchange uses small packets) but data packets will not get through Is that correct understanding? Regards Yuri Suresh Krishnan wrote: > Hi Yuri, > Thanks for your comments. > > Cheers > Suresh > > On 10-02-01 11:25 AM, Yuri Ismailov wrote: >> Hi, >> I reviewed the draft draft-ietf-mext-firewall-admin-02. >> The document looks quite solid and addresses all important issues. > > Sounds good. > >> >> However, there is one issue, in my opinion, which was left aside in the >> draft. >> I think that the section 6.2 should be completed with the recommendations >> about letting specific ICMPv4 error messages to pass through firewalls. > > You are right. We did not think about this as DSMIPv6 was a late > addition to this document. It makes sense to add these recommendations. > >> This has >> to do with the path MTU discovery. Because this draft is concerned the >> firewall traversal, there is no need to talk about MTU tuning, however, >> I believe that firewall traversal is worth while mentioning. >> There is a reference to RFC 4890 at the end, which is concerned with >> ICMPv6 only. >> When using DSMIPv6 with NAT traversal, ICMPv4 error messages regarding >> MTU size >> could be sent as well. Thus the suggestion is to additionally refer the >> specifications >> RFC1191 and RFC1981, specifying path MTU discovery for IPv4 and IPv6 >> correspondingly. > > OK. > >> >> I suggest to add some text (see proposal below) at the end of the >> section 6.2, which specifically addresses data packets for DSMIPv6. >> Signaling packets probably not that important as MTU sizes will not be >> exceeded, >> or in case it will happen, the result will be anyway ICMPv4 error >> messages as >> signaling will be UDP encapsulated as well. >> >> Proposed text at the end of the section 6.2 >> >> When using DSMIPv6 with NAT traversal, the MTU sizes and correspondingly >> Maximum >> Segment Size (MSS) for TCP will have to be reduced due to the number >> of encapsulation headers in the data and signaling packets. This creates >> a need >> for path MTU discovery (RFC1191, RFC1981) to be supported in the >> infrastructure >> for visited networks and HA as well. As DSMIPv6 NAT traversal mechanism >> suggests >> using IPv4/UDP encapsulation of packets, the above mentioned path MTU >> discovery >> procedure may involve ICMPv4 "Destination Unreachable, fragmentation >> needed and DF set" >> (RFC792) message to be returned to the sender. This message may be sent >> by any node >> along the path including mobile node itself. In the case mobile node >> resides behind >> firewall, the firewall should let this type of packet (ICMP type 3, code >> 4) through, >> in order the messages could reach the sender. The same recommendation >> applies to the >> firewalls in mobile's node Home Network. > > Looks good. Will add the text. > > Thanks > Suresh > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From suresh.krishnan@ericsson.com Mon Feb 1 22:34:05 2010 Return-Path: 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 DBCDE3A6818 for ; Mon, 1 Feb 2010 22:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=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 CsggpaSsnsW9 for ; Mon, 1 Feb 2010 22:34:01 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 28E523A6A7F for ; Mon, 1 Feb 2010 22:34:01 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o126ZhUF029913; Tue, 2 Feb 2010 00:35:43 -0600 Received: from [142.133.10.113] (147.117.20.212) by eusaamw0706.eamcs.ericsson.se (147.117.20.91) with Microsoft SMTP Server id 8.1.375.2; Tue, 2 Feb 2010 01:34:36 -0500 Message-ID: <4B67C68E.5010809@ericsson.com> Date: Tue, 2 Feb 2010 01:30:38 -0500 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Yuri Ismailov References: <4B5EAB2A.9030404@it.uc3m.es> <4B67006D.3010006@ismailov.eu> <4B674186.2050008@ericsson.com> <4B674862.3060000@ismailov.eu> In-Reply-To: <4B674862.3060000@ismailov.eu> Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Cc: mext Subject: Re: [MEXT] Draft Review 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: , X-List-Received-Date: Tue, 02 Feb 2010 06:34:05 -0000 Hi Yuri, On 10-02-01 04:32 PM, Yuri Ismailov wrote: > Hi, > After sending comment about path MTU I just thought that things could be > more serious than that.This is not related to the draft for FW > traversal, but I want to share my concerns here.with the group. > > Assume that infrastructure works as it should and path MTU discovery > implemented and functional in all nodes. Firewalls are opened for > necessary traffic to path through. > > However, when using DSMIPv6 with NAT traversal, the outer header > contains source IP address, which is HA IPv4 address. Any intermediary > node, in case of less MTU along the next hop will send ICMP Host > Unreachable to the HA. Basically, the ICMP will never reach CN, which > will keep sending packets with the same MTU, exceeding the required one. > This has bad consequences. For example TCP connection will be > established (SYN exchange uses small packets) but data packets will not > get through > > Is that correct understanding? Not really. The HA will need to discover and remember the path MTU on its tunnel interface. If it gets an incoming packet from the CN larger than the tunnel MTU, it will send a dest unreachable code 4 message towards the CN. Cheers Suresh From root@core3.amsl.com Tue Feb 9 08:15:02 2010 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 48F983A73F5; Tue, 9 Feb 2010 08:15:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100209161502.48F983A73F5@core3.amsl.com> Date: Tue, 9 Feb 2010 08:15:02 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-binary-ts-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: , X-List-Received-Date: Tue, 09 Feb 2010 16:15:02 -0000 --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 : Traffic Selectors for Flow Bindings Author(s) : G. Tsirtsis, et al. Filename : draft-ietf-mext-binary-ts-03.txt Pages : 19 Date : 2010-02-09 This document defines binary formats for IPv4 and IPv6 traffic selectors to be used in conjunction with flow bindings for Mobile IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-binary-ts-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-binary-ts-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-09080018.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue Feb 9 08:30:02 2010 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 81E8D3A7223; Tue, 9 Feb 2010 08:30:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100209163002.81E8D3A7223@core3.amsl.com> Date: Tue, 9 Feb 2010 08:30:01 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-flow-binding-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: , X-List-Received-Date: Tue, 09 Feb 2010 16:30:02 -0000 --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-05.txt Pages : 37 Date : 2010-02-09 This document introduces extensions to Mobile IPv6 that allow nodes to bind one or more flows to a care-of address. These extensions allow multihomed nodes to instruct home agents and other Mobile IPv6 entities to direct inbound flows to specific addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-flow-binding-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-mext-flow-binding-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-09082828.I-D@ietf.org> --NextPart-- From marcelo@it.uc3m.es Wed Feb 10 00:10:59 2010 Return-Path: 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 E75CD28C116 for ; Wed, 10 Feb 2010 00:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.423 X-Spam-Level: X-Spam-Status: No, score=-106.423 tagged_above=-999 required=5 tests=[AWL=0.176, 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 7HRiCOJ2k7oi for ; Wed, 10 Feb 2010 00:10:58 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 9B48628C131 for ; Wed, 10 Feb 2010 00:10:58 -0800 (PST) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.31.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id CD08BB9FCAC for ; Wed, 10 Feb 2010 09:12:05 +0100 (CET) Message-ID: <4B726A48.8020409@it.uc3m.es> Date: Wed, 10 Feb 2010 09:11:52 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Subject: [MEXT] flow binding draft send to IESG 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: , X-List-Received-Date: Wed, 10 Feb 2010 08:11:00 -0000 Thanks for the good work everyone and special thanks to George for taking care of the last comments. Regards, marcelo From Xiangsong.Cui@huawei.com Wed Feb 10 23:50:41 2010 Return-Path: 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 18FDA3A7808 for ; Wed, 10 Feb 2010 23:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 0dVaWvlGD+Ab for ; Wed, 10 Feb 2010 23:50:40 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 54B8C3A7352 for ; Wed, 10 Feb 2010 23:50:38 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXO00IGC362LI@szxga04-in.huawei.com> for mext@ietf.org; Thu, 11 Feb 2010 15:51:39 +0800 (CST) Received: from c00111037 ([10.111.16.88]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXO0060C362OX@szxga04-in.huawei.com> for mext@ietf.org; Thu, 11 Feb 2010 15:51:38 +0800 (CST) Date: Thu, 11 Feb 2010 15:51:38 +0800 From: Xiangsong Cui To: marcelo bagnulo braun , mext Message-id: <014301caaaef$0ac72750$58106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4B5EAB2A.9030404@it.uc3m.es> Subject: [MEXT] A new draft for firewall issue 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: , X-List-Received-Date: Thu, 11 Feb 2010 07:50:41 -0000 Dear Marcelo and all, I have read the drafts and I think the drafts are in good shape. Additionally, I think the trouble we are facing is the incompatibility of firewall and mobility messages, or the conflict between firewall filter and mobility management (e.g. care-of address). These two drafts resolve the trouble by firewall enhancement and configuration, this is really an effective approach. On the other hand, I am thinking can we extend the procedure of mobility management to resolve this incompatibility? I submitted a draft for this approach, http://tools.ietf.org/id/draft-cui-mext-firewall-traversing-00.txt Is that considerable? Any comment is appreciated! Xiangsong ----- Original Message ----- From: "marcelo bagnulo braun" To: "mext" Sent: Tuesday, January 26, 2010 4:43 PM Subject: [MEXT] WGLC for firewall drafts > This is the WGLC for the two drafts related to firewall and MIPv6 i.e. > draft-ietf-mext-firewall-admin-02.txt and > draft-ietf-mext-firewall-vendor-02.txt. > > Please review the documents and send comments until Feb 15. > > For you convenience, the drafts can be found at: > > http://www.ietf.org/id/draft-ietf-mext-firewall-admin-02.txt > http://www.ietf.org/id/draft-ietf-mext-firewall-vendor-02.txt > > Regards, marcelo > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From charles.perkins@earthlink.net Mon Feb 15 10:11:09 2010 Return-Path: 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 158FF3A7BBA for ; Mon, 15 Feb 2010 10:11:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 FjbX7uZe2q3I for ; Mon, 15 Feb 2010 10:11:06 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id DB8F63A7BB9 for ; Mon, 15 Feb 2010 10:11:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=PPGjZYD+2KPUwfWSvu41ucRp9R4aUI6OebH1GR5dUKJD94CpYkhXzdyKLENcBCnb; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.12]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Nh5Qy-0004P4-Um for mext@ietf.org; Mon, 15 Feb 2010 13:12:37 -0500 Message-ID: <4B798E91.2070003@earthlink.net> Date: Mon, 15 Feb 2010 10:12:33 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f521b3eae58c4dc486e3d65ae506583cb00350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Subject: [MEXT] rfc3775bis ticket #7: "DSMIPv6 BU format and RFC 3775" --- close? 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: , X-List-Received-Date: Mon, 15 Feb 2010 18:11:09 -0000 Hello folks, I have reviewed the issue and following discussion. There has not been any new discussion on the mailing list in a long time. You can see the discussion on the issue tracker web page: http://trac.tools.ietf.org/wg/mext/trac/ticket/7 Almost all of the discussion centered around likely problems with DSMIPv6 wording. There was some relevance to rfc3775bis, but I don't think there was very persuasive argument for making any changes to rfc3775bis. In preparation for submitting another revision of rfc3775bis for publication this week, I recommend closing this issue without change to the document. Regards, Charlie P. From charles.perkins@earthlink.net Mon Feb 15 15:19:11 2010 Return-Path: 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 E94B83A7BE4 for ; Mon, 15 Feb 2010 15:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 ZOSVCCdEhbjf for ; Mon, 15 Feb 2010 15:19:11 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 334EF28C12F for ; Mon, 15 Feb 2010 15:19:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=gQF4WgnRQfc5oJaymSdF0B+MoP2GpdiHsH11qC14Ss8QOtMZWH6NaSWWnMoa3dkB; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.12]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1NhAF8-00075z-5i for mext@ietf.org; Mon, 15 Feb 2010 18:20:43 -0500 Message-ID: <4B79D6BE.6060003@earthlink.net> Date: Mon, 15 Feb 2010 15:20:30 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f522f953d01552263f3267a7713a42eb76b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Subject: [MEXT] rfc3775bis ticket #18: "Issues regarding Home Address Option & ICMP / Binding errors" --- resolutions accepted, so should close. 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: , X-List-Received-Date: Mon, 15 Feb 2010 23:19:12 -0000 Hello folks, Last summer there was some discussion on rfc3775bis ticket #18. The discussion can be reviewed on the web page: http://trac.tools.ietf.org/wg/mext/trac/ticket/18 This ticket actually describes three generally different issues, each of which received individual attention on the mailing list and which had independent resolutions. Pertinent discussion is condensed and shown on the above-mentioned web page. Since then, there has been no discussion, and noone has objected to the proposed resolutions to the three separate issues. The text of the proposed resolutions has been included in draft-ietf-mext-rfc3775bis-05, so the issue should have been closed already. I'll do that soon. Regards, Charlie P. From charles.perkins@earthlink.net Mon Feb 15 15:38:38 2010 Return-Path: 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 E4E9A3A7BED for ; Mon, 15 Feb 2010 15:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 N8AfbM8aQwBO for ; Mon, 15 Feb 2010 15:38:38 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 1FF2C3A7BE9 for ; Mon, 15 Feb 2010 15:38:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Y7+ZdruRSQivnhYnHOIW0BTLefvAS+yPWWfFry/hQZX3AySEbvIyRW33635grfmY; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.12]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1NhAXx-0000xj-Ty for mext@ietf.org; Mon, 15 Feb 2010 18:40:10 -0500 Message-ID: <4B79DB58.8040200@earthlink.net> Date: Mon, 15 Feb 2010 15:40:08 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f522198910bf7fc4f6b6ee57e6f0ca17187350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Subject: [MEXT] rfc3775bis ticket #19: "BU de-registration race condition" --- resolution accepted, so should close. 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: , X-List-Received-Date: Mon, 15 Feb 2010 23:38:39 -0000 Hello folks, The discussion for rfc3775bis ticket #19 can be reviewed on the web page: http://trac.tools.ietf.org/wg/mext/trac/ticket/19 There was some useful discussion about this issue on the mailing list, and a resolution was reached that I think was generally quite satisfactory. The text of the proposed resolution has been included in draft-ietf-mext-rfc3775bis-05. Since then, there has been no discussion, and noone has raised any objection, so the issue should have been closed already. I'll do that soon. Regards, Charlie P. From charles.perkins@earthlink.net Mon Feb 15 15:48:58 2010 Return-Path: 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 C17A028C14D for ; Mon, 15 Feb 2010 15:48:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 Gyky2DPLd0Ot for ; Mon, 15 Feb 2010 15:48:58 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 1EFCB28C145 for ; Mon, 15 Feb 2010 15:48:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=cRq+6+CUV6xd11WMhwbyQ3e9wTGaCgfuF+6G1z8rJkh52bu0dLOSaKp3xmPds66h; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.12]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1NhAhy-0002Wl-66 for mext@ietf.org; Mon, 15 Feb 2010 18:50:30 -0500 Message-ID: <4B79DDC3.3050304@earthlink.net> Date: Mon, 15 Feb 2010 15:50:27 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5272c95d6777c29d58cf24c0033fd40e4e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Subject: [MEXT] rfc3775bis Issue #19 (BU de-registration race condition) discussion 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: , X-List-Received-Date: Mon, 15 Feb 2010 23:48:58 -0000 Hello folks, It looks like I sent that last e-mail just a few minutes too soon. I did find some more discussion about the BU de-registration race condition. I will review it and summarize for the list. Regards, Charlie P. From trac@tools.ietf.org Mon Feb 15 16:23:30 2010 Return-Path: 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 D18A528C13A for ; Mon, 15 Feb 2010 16:23:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.234 X-Spam-Level: X-Spam-Status: No, score=-102.234 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 m6peq4WVTtKE for ; Mon, 15 Feb 2010 16:23:29 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 84CBE28C122 for ; Mon, 15 Feb 2010 16:23:29 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NhBFI-0005ZP-GU; Mon, 15 Feb 2010 16:24:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mext Issue Tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: charliep@computer.org X-Trac-Project: mext Date: Tue, 16 Feb 2010 00:24:56 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mext/trac/ticket/19#comment:1 Message-ID: <072.0ebf0e7958d9b71090da4cb9a69d2b78@tools.ietf.org> References: <063.f0856a6475bc065af553287766feaa69@tools.ietf.org> X-Trac-Ticket-ID: 19 In-Reply-To: <063.f0856a6475bc065af553287766feaa69@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, Kilian.Weniger@eu.panasonic.com, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: Kilian.Weniger@eu.panasonic.com, mext@ietf.org Subject: Re: [MEXT] [mext] #19: BU de-registration race condition X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Reply-To: mext@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 00:23:31 -0000 #19: BU de-registration race condition ---------------------------------------------------------+------------------ Reporter: charliep@… | Owner: charliep@… Type: defect | Status: closed Priority: minor | Milestone: IETF76 Component: draft-ietf-mext-rfc3775bis | Version: 5.0 Severity: Active WG Document | Resolution: fixed Keywords: Mobile IPv6, Binding Update, race condition | ---------------------------------------------------------+------------------ Changes (by charliep@…): * status: new => closed * version: 4.0 => 5.0 * resolution: => fixed * milestone: IETF75 => IETF76 Comment: ============================================================================ Basavaraj Patil: In Rev 5 of the I-D posted at the URL in your earlier email, Sec 10.3.2 states: When the Status field in the Binding Acknowledgement is greater than or equal to 128 and the Source Address of the Binding Update is on the home link, the home agent MUST send it to the mobile node's link layer address (retrieved either from the Binding Update or through Neighbor Solicitation). The MN may be on a virtual HL and hence there may not be a LLA for the MN to which the BAck can be sent. IMO the above sentence should be revised by deleting the part about sending it to the LLA and the clarification in the parentheses. ============================================================================ Charles E. Perkins: What if I add another clause, to say that the mandate is placed when the Binding Update came from a mobile node on the same link? The result is: When the Status field in the Binding Acknowledgement is greater than or equal to 128 and the Source Address of the Binding Update is on the home link, and the Binding Update came from a mobile node on the same link, the home agent MUST send it to the mobile node's link layer address (retrieved either from the Binding Update or through Neighbor Solicitation). ============================================================================ -- Ticket URL: mext From charles.perkins@earthlink.net Mon Feb 15 16:29:31 2010 Return-Path: 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 D210D3A71D3 for ; Mon, 15 Feb 2010 16:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 mvc4gm7+XMs7 for ; Mon, 15 Feb 2010 16:29:31 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 1C7EB3A6919 for ; Mon, 15 Feb 2010 16:29:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=kHz4pxeeBBB0FMhHEmHvbgqH+43sEu5q3MvE9XQRkQN/Nb2JVQWxNn4rja/VEk65; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.12]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1NhBLC-0003hz-BB; Mon, 15 Feb 2010 19:31:02 -0500 Message-ID: <4B79E742.1090709@earthlink.net> Date: Mon, 15 Feb 2010 16:30:58 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f525ef5659cdb4064929e948a48f63b2907350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: "mext-chairs@tools.ietf.org" Subject: [MEXT] rfc3775 issues resolved. 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: , X-List-Received-Date: Tue, 16 Feb 2010 00:29:31 -0000 Hello folks, I have looked over the mailing list since last summer, and reviewed the IETF 76 minutes. The only additional material I found was already incorporated into draft-ietf-mext-rfc3775bis-05. I updated the text on the issues tracker for ticket #19 (BU de-registration race condition). I think all three issues can be considered resolved and closed. I didn't find any new issues, but if I missed anything please let me know ASAP. The existing draft does not expire until April (after the next IETF). If there are no other issues, I guess the draft is ready to be sent to the IESG. Regards, Charlie P. From alexandru.petrescu@gmail.com Wed Feb 17 09:41:30 2010 Return-Path: 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 8B09528C110 for ; Wed, 17 Feb 2010 09:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 Fk49NlQ07HLo for ; Wed, 17 Feb 2010 09:41:30 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 9E7773A7D14 for ; Wed, 17 Feb 2010 09:41:29 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o1HHh7u6005452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 17 Feb 2010 18:43:07 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o1HHh7SG023635 for ; Wed, 17 Feb 2010 18:43:07 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o1HHh7tN020979 for ; Wed, 17 Feb 2010 18:43:07 +0100 Message-ID: <4B7C2AAB.5070801@gmail.com> Date: Wed, 17 Feb 2010 18:43:07 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: mext@ietf.org References: <4B79E742.1090709@earthlink.net> In-Reply-To: <4B79E742.1090709@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [MEXT] Licensing scheme for several drafts in MEXT WG 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: , X-List-Received-Date: Wed, 17 Feb 2010 17:41:30 -0000 WG members - hello, First yes I agree with the Note Well and I will discuss licensing in tlp-interest list, ok, thanks. I wanted to state publicly here that I do not agree with the licensing scheme which may apply to several drafts in this WG related to MIP6 (rfc3775bis, prefix delegation, v4traversal) (i.e. if you use ipr attribute "trust200902" in xml, if xml2rfc is used). I do not agree with the statement "Code Components extracted from this document... BSD license". I am doing so because I think I may have made technical remarks on these drafts, in the past, but now I realize the new licensing scheme ("trust200902") may not suit me well. End of statement, it's here posted in MEXT, thanks. Alex From marcelo@it.uc3m.es Wed Feb 17 10:07:33 2010 Return-Path: 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 7A7E828C0E1 for ; Wed, 17 Feb 2010 10:07:33 -0800 (PST) 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 aE+q1fpbmYES for ; Wed, 17 Feb 2010 10:07:32 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 8CB4E3A7D50 for ; Wed, 17 Feb 2010 10:07:32 -0800 (PST) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (19.102.218.87.dynamic.jazztel.es [87.218.102.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id E0DA3BAB3F1 for ; Wed, 17 Feb 2010 19:09:08 +0100 (CET) Message-ID: <4B7C30C2.4030604@it.uc3m.es> Date: Wed, 17 Feb 2010 19:09:06 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: mext@ietf.org References: <4B79E742.1090709@earthlink.net> <4B7C2AAB.5070801@gmail.com> In-Reply-To: <4B7C2AAB.5070801@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Subject: Re: [MEXT] Licensing scheme for several drafts in MEXT WG 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: , X-List-Received-Date: Wed, 17 Feb 2010 18:07:33 -0000 Hi Alex, reply below El 17/02/10 18:43, Alexandru Petrescu escribió: > WG members - hello, > > First yes I agree with the Note Well and I will discuss licensing in > tlp-interest list, ok, thanks. > > I wanted to state publicly here that I do not agree with the licensing > scheme which may apply to several drafts in this WG related to MIP6 > > (rfc3775bis, prefix delegation, v4traversal) there is nothing we can about v4 traversal since it already publish as RFC, but with respect the other two, what do you suggest we do? or you just want to state your unhapiness with the IPR approach in general wihtout any alternative approach the WG can take? If that is the case, it is noted. If not, please propose what would be your alternative approach and see if we can do it. Regards, marcelo > (i.e. if you use ipr > attribute "trust200902" in xml, if xml2rfc is used). I do not agree > with the statement "Code Components extracted from this document... BSD > license". > > I am doing so because I think I may have made technical remarks on these > drafts, in the past, but now I realize the new licensing scheme > ("trust200902") may not suit me well. > > End of statement, it's here posted in MEXT, thanks. > > Alex > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From alexandru.petrescu@gmail.com Wed Feb 17 10:29:07 2010 Return-Path: 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 E74BD3A7D88 for ; Wed, 17 Feb 2010 10:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_19=0.6] 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 mUfTCes99yhQ for ; Wed, 17 Feb 2010 10:29:07 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id CA2CE3A7349 for ; Wed, 17 Feb 2010 10:29:06 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o1HIUj3T023948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 17 Feb 2010 19:30:45 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o1HIUiuW029468 for ; Wed, 17 Feb 2010 19:30:44 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o1HIUhqm030885 for ; Wed, 17 Feb 2010 19:30:44 +0100 Message-ID: <4B7C35D4.1070206@gmail.com> Date: Wed, 17 Feb 2010 19:30:44 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: mext@ietf.org References: <4B79E742.1090709@earthlink.net> <4B7C2AAB.5070801@gmail.com> <4B7C30C2.4030604@it.uc3m.es> In-Reply-To: <4B7C30C2.4030604@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MEXT] Licensing scheme for several drafts in MEXT WG 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: , X-List-Received-Date: Wed, 17 Feb 2010 18:29:08 -0000 MArcelo, hi, thank you for asking. I must be very careful here because in several WGs I have been strongly redirected to tlp-interest. Briefly. Le 17/02/2010 19:09, marcelo bagnulo braun a écrit : > Hi Alex, > > reply below > > El 17/02/10 18:43, Alexandru Petrescu escribió: >> WG members - hello, >> >> First yes I agree with the Note Well and I will discuss licensing >> in tlp-interest list, ok, thanks. >> >> I wanted to state publicly here that I do not agree with the >> licensing scheme which may apply to several drafts in this WG >> related to MIP6 >> >> (rfc3775bis, prefix delegation, v4traversal) > > there is nothing we can about v4 traversal since it already publish > as RFC, YEs, I agree, sorry, I missed that v4traversal became RFC, and congratulations. Indeed RFC5555 has its licensing ok with me - it doesn't say "BSD". > but with respect the other two, what do you suggest we do? Well, principally I suggest changing the boilerplate. I will come here later if the use arises when the "Code Componets" text appears in the draft, when draft authors will use the necessary(?) ipr attribute, if xml2rfc is used. > or you just want to state your unhapiness with the IPR approach in > general wihtout any alternative approach the WG can take? I am unhappy about the licensing, not necessarily IPR. Several IPR disclosures at IETF are ok with me. What bothers me right now is the "BSD" licensing appearing in every draft. (search "BSD" or "Code Components" in recent drafts, seems mandatory). > If that is the case, it is noted. YEs, please note I am unhappy with the boilerplate saying "Code Components extracted from this document... BSD". Especially when it tags the drafts to which I may have commented technically. > If not, please propose what would be your alternative approach and > see if we can do it. WEll, each draft - prefix delegation, rfc3775bis - may need a different licensing approach; the main idea would be to give freedom to the implementer to tag the license s/he wants, not necessarily BSD. This was the case in the past, prior to the most recent boilerplate. (sorry when I try to discuss this many strange things happen like automatically getting subscribed to -honest, bounces from trustees, and more, I must be very careful). Thanks, Alex > > Regards, marcelo > > >> (i.e. if you use ipr attribute "trust200902" in xml, if xml2rfc is >> used). I do not agree with the statement "Code Components >> extracted from this document... BSD license". >> >> I am doing so because I think I may have made technical remarks on >> these drafts, in the past, but now I realize the new licensing >> scheme ("trust200902") may not suit me well. >> >> End of statement, it's here posted in MEXT, thanks. >> >> Alex >> >> _______________________________________________ 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 marcelo@it.uc3m.es Wed Feb 17 10:47:37 2010 Return-Path: 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 A51B928C1C0 for ; Wed, 17 Feb 2010 10:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_19=0.6, 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 KgMyJVD49eIk for ; Wed, 17 Feb 2010 10:47:36 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 2887C28C1A7 for ; Wed, 17 Feb 2010 10:47:36 -0800 (PST) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (19.102.218.87.dynamic.jazztel.es [87.218.102.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 985E7BAB3E2 for ; Wed, 17 Feb 2010 19:49:13 +0100 (CET) Message-ID: <4B7C3A27.2040505@it.uc3m.es> Date: Wed, 17 Feb 2010 19:49:11 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: mext@ietf.org References: <4B79E742.1090709@earthlink.net> <4B7C2AAB.5070801@gmail.com> <4B7C30C2.4030604@it.uc3m.es> <4B7C35D4.1070206@gmail.com> In-Reply-To: <4B7C35D4.1070206@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Subject: Re: [MEXT] Licensing scheme for several drafts in MEXT WG 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: , X-List-Received-Date: Wed, 17 Feb 2010 18:47:37 -0000 Alex, simple question: is there any of the current available attributes in xml2rfc that are ok with you for rfc3775bis or for nemo pd? If yes could you provide a concrete suggestion of what the attribute you propose we use for each of the draft so the WG can comment. Regards, marcelo El 17/02/10 19:30, Alexandru Petrescu escribió: > MArcelo, hi, thank you for asking. > > I must be very careful here because in several WGs I have been strongly > redirected to tlp-interest. > > Briefly. > > Le 17/02/2010 19:09, marcelo bagnulo braun a écrit : >> Hi Alex, >> >> reply below >> >> El 17/02/10 18:43, Alexandru Petrescu escribió: >>> WG members - hello, >>> >>> First yes I agree with the Note Well and I will discuss licensing >>> in tlp-interest list, ok, thanks. >>> >>> I wanted to state publicly here that I do not agree with the >>> licensing scheme which may apply to several drafts in this WG >>> related to MIP6 >>> >>> (rfc3775bis, prefix delegation, v4traversal) >> >> there is nothing we can about v4 traversal since it already publish >> as RFC, > > YEs, I agree, sorry, I missed that v4traversal became RFC, and > congratulations. Indeed RFC5555 has its licensing ok with me - it > doesn't say "BSD". > >> but with respect the other two, what do you suggest we do? > > Well, principally I suggest changing the boilerplate. I will come here > later if the use arises when the "Code Componets" text appears in the > draft, when draft authors will use the necessary(?) ipr attribute, if > xml2rfc is used. > >> or you just want to state your unhapiness with the IPR approach in >> general wihtout any alternative approach the WG can take? > > I am unhappy about the licensing, not necessarily IPR. Several IPR > disclosures at IETF are ok with me. What bothers me right now is the > "BSD" licensing appearing in every draft. (search "BSD" or "Code > Components" in recent drafts, seems mandatory). > >> If that is the case, it is noted. > > YEs, please note I am unhappy with the boilerplate saying "Code > Components extracted from this document... BSD". Especially when it > tags the drafts to which I may have commented technically. > >> If not, please propose what would be your alternative approach and >> see if we can do it. > > WEll, each draft - prefix delegation, rfc3775bis - may need a different > licensing approach; the main idea would be to give freedom to the > implementer to tag the license s/he wants, not necessarily BSD. This > was the case in the past, prior to the most recent boilerplate. > > (sorry when I try to discuss this many strange things happen like > automatically getting subscribed to -honest, bounces from trustees, > and more, I must be very careful). > > Thanks, > > Alex > > >> >> Regards, marcelo >> >> >>> (i.e. if you use ipr attribute "trust200902" in xml, if xml2rfc is >>> used). I do not agree with the statement "Code Components >>> extracted from this document... BSD license". >>> >>> I am doing so because I think I may have made technical remarks on >>> these drafts, in the past, but now I realize the new licensing >>> scheme ("trust200902") may not suit me well. >>> >>> End of statement, it's here posted in MEXT, thanks. >>> >>> Alex >>> >>> _______________________________________________ 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 alexandru.petrescu@gmail.com Wed Feb 17 12:45:35 2010 Return-Path: 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 2FFD93A7BC5 for ; Wed, 17 Feb 2010 12:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.303 X-Spam-Level: X-Spam-Status: No, score=-1.303 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_19=0.6] 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 yiyOLaHkgxJh for ; Wed, 17 Feb 2010 12:45:34 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id E131D28C0EF for ; Wed, 17 Feb 2010 12:45:32 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 303EFD48173 for ; Wed, 17 Feb 2010 21:47:08 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 250DFD480A6 for ; Wed, 17 Feb 2010 21:47:05 +0100 (CET) Message-ID: <4B7C55C7.80402@gmail.com> Date: Wed, 17 Feb 2010 21:47:03 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: mext@ietf.org References: <4B79E742.1090709@earthlink.net> <4B7C2AAB.5070801@gmail.com> <4B7C30C2.4030604@it.uc3m.es> <4B7C35D4.1070206@gmail.com> <4B7C3A27.2040505@it.uc3m.es> In-Reply-To: <4B7C3A27.2040505@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100217-1, 17/02/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [MEXT] Licensing scheme for several drafts in MEXT WG 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: , X-List-Received-Date: Wed, 17 Feb 2010 20:45:35 -0000 Le 17/02/2010 19:49, marcelo bagnulo braun a écrit : > Alex, > > simple question: is there any of the current available attributes in > xml2rfc that are ok with you for rfc3775bis or for nemo pd? If yes > could you provide a concrete suggestion of what the attribute you > propose we use for each of the draft so the WG can comment. I don't know what to say. All I can do is wait :-) I am trying to identify the ipr attribute (ipr="xxx" in xml sources) which leads to the best boilerplate which bests suits my interests for MEXT drafts. In order to do that I am seeking advice on several lists. The most relevant seems to be the list xml2rfc@xml.resource.org. However I can't post to it after several tests, and new re-subscription (just another strangeness). I have sent private email to a person ask for help. I hope it's simply a technical issue. Also I am privately told that xml2rfc may not be up to date with the most recent Trust provisions. Another interesting list is tlp-interest but which should be accompanied by a post Cc to trustees@ietf.org, from which I get bounces. I do not know how to interpret it - is it simply a technical error? Is it that the Trustees don't want mail from me? It's strange to ask a Cc to trustees@ietf.org only to bounce it back... I am trying to keep things as simple as possible but this is sometimes too complicated for me. I am waiting :-) Alex > Regards, marcelo > > > El 17/02/10 19:30, Alexandru Petrescu escribió: >> MArcelo, hi, thank you for asking. >> >> I must be very careful here because in several WGs I have been >> strongly redirected to tlp-interest. >> >> Briefly. >> >> Le 17/02/2010 19:09, marcelo bagnulo braun a écrit : >>> Hi Alex, >>> >>> reply below >>> >>> El 17/02/10 18:43, Alexandru Petrescu escribió: >>>> WG members - hello, >>>> >>>> First yes I agree with the Note Well and I will discuss >>>> licensing in tlp-interest list, ok, thanks. >>>> >>>> I wanted to state publicly here that I do not agree with the >>>> licensing scheme which may apply to several drafts in this WG >>>> related to MIP6 >>>> >>>> (rfc3775bis, prefix delegation, v4traversal) >>> >>> there is nothing we can about v4 traversal since it already >>> publish as RFC, >> >> YEs, I agree, sorry, I missed that v4traversal became RFC, and >> congratulations. Indeed RFC5555 has its licensing ok with me - it >> doesn't say "BSD". >> >>> but with respect the other two, what do you suggest we do? >> >> Well, principally I suggest changing the boilerplate. I will come >> here later if the use arises when the "Code Componets" text >> appears in the draft, when draft authors will use the necessary(?) >> ipr attribute, if xml2rfc is used. >> >>> or you just want to state your unhapiness with the IPR approach >>> in general wihtout any alternative approach the WG can take? >> >> I am unhappy about the licensing, not necessarily IPR. Several IPR >> disclosures at IETF are ok with me. What bothers me right now is >> the "BSD" licensing appearing in every draft. (search "BSD" or >> "Code Components" in recent drafts, seems mandatory). >> >>> If that is the case, it is noted. >> >> YEs, please note I am unhappy with the boilerplate saying "Code >> Components extracted from this document... BSD". Especially when it >> tags the drafts to which I may have commented technically. >> >>> If not, please propose what would be your alternative approach >>> and see if we can do it. >> >> WEll, each draft - prefix delegation, rfc3775bis - may need a >> different licensing approach; the main idea would be to give >> freedom to the implementer to tag the license s/he wants, not >> necessarily BSD. This was the case in the past, prior to the most >> recent boilerplate. >> >> (sorry when I try to discuss this many strange things happen like >> automatically getting subscribed to -honest, bounces from trustees, >> and more, I must be very careful). >> >> Thanks, >> >> Alex >> >> >>> >>> Regards, marcelo >>> >>> >>>> (i.e. if you use ipr attribute "trust200902" in xml, if >>>> xml2rfc is used). I do not agree with the statement "Code >>>> Components extracted from this document... BSD license". >>>> >>>> I am doing so because I think I may have made technical >>>> remarks on these drafts, in the past, but now I realize the >>>> new licensing scheme ("trust200902") may not suit me well. >>>> >>>> End of statement, it's here posted in MEXT, thanks. >>>> >>>> Alex >>>> >>>> _______________________________________________ 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 marcelo@it.uc3m.es Wed Feb 17 12:50:47 2010 Return-Path: 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 8AC6C28C14A for ; Wed, 17 Feb 2010 12:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.149 X-Spam-Level: X-Spam-Status: No, score=-106.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_19=0.6, 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 YQR++W2kjOOj for ; Wed, 17 Feb 2010 12:50:46 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id CB7693A7F1E for ; Wed, 17 Feb 2010 12:50:45 -0800 (PST) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (19.102.218.87.dynamic.jazztel.es [87.218.102.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id C096BBAB2AC for ; Wed, 17 Feb 2010 21:52:23 +0100 (CET) Message-ID: <4B7C5705.2070209@it.uc3m.es> Date: Wed, 17 Feb 2010 21:52:21 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: mext@ietf.org References: <4B79E742.1090709@earthlink.net> <4B7C2AAB.5070801@gmail.com> <4B7C30C2.4030604@it.uc3m.es> <4B7C35D4.1070206@gmail.com> <4B7C3A27.2040505@it.uc3m.es> <4B7C55C7.80402@gmail.com> In-Reply-To: <4B7C55C7.80402@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Subject: Re: [MEXT] Licensing scheme for several drafts in MEXT WG 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: , X-List-Received-Date: Wed, 17 Feb 2010 20:50:47 -0000 ok, when you do have a concrete proposal, bring to the WG for consideration. regards, marcelo El 17/02/10 21:47, Alexandru Petrescu escribió: > Le 17/02/2010 19:49, marcelo bagnulo braun a écrit : >> Alex, >> >> simple question: is there any of the current available attributes in >> xml2rfc that are ok with you for rfc3775bis or for nemo pd? If yes >> could you provide a concrete suggestion of what the attribute you >> propose we use for each of the draft so the WG can comment. > > I don't know what to say. All I can do is wait :-) > > I am trying to identify the ipr attribute (ipr="xxx" in xml sources) > which leads to the best boilerplate which bests suits my interests for > MEXT drafts. In order to do that I am seeking advice on several lists. > > The most relevant seems to be the list xml2rfc@xml.resource.org. > However I can't post to it after several tests, and new re-subscription > (just another strangeness). I have sent private email to a person ask > for help. I hope it's simply a technical issue. > > Also I am privately told that xml2rfc may not be up to date with the > most recent Trust provisions. > > Another interesting list is tlp-interest but which should be > accompanied by a post Cc to trustees@ietf.org, from which I get > bounces. I do not know how to interpret it - is it simply a technical > error? Is it that the Trustees don't want mail from me? It's strange > to ask a Cc to trustees@ietf.org only to bounce it back... > > I am trying to keep things as simple as possible but this is sometimes > too complicated for me. > > I am waiting :-) > > Alex > >> Regards, marcelo >> >> >> El 17/02/10 19:30, Alexandru Petrescu escribió: >>> MArcelo, hi, thank you for asking. >>> >>> I must be very careful here because in several WGs I have been >>> strongly redirected to tlp-interest. >>> >>> Briefly. >>> >>> Le 17/02/2010 19:09, marcelo bagnulo braun a écrit : >>>> Hi Alex, >>>> >>>> reply below >>>> >>>> El 17/02/10 18:43, Alexandru Petrescu escribió: >>>>> WG members - hello, >>>>> >>>>> First yes I agree with the Note Well and I will discuss >>>>> licensing in tlp-interest list, ok, thanks. >>>>> >>>>> I wanted to state publicly here that I do not agree with the >>>>> licensing scheme which may apply to several drafts in this WG >>>>> related to MIP6 >>>>> >>>>> (rfc3775bis, prefix delegation, v4traversal) >>>> >>>> there is nothing we can about v4 traversal since it already >>>> publish as RFC, >>> >>> YEs, I agree, sorry, I missed that v4traversal became RFC, and >>> congratulations. Indeed RFC5555 has its licensing ok with me - it >>> doesn't say "BSD". >>> >>>> but with respect the other two, what do you suggest we do? >>> >>> Well, principally I suggest changing the boilerplate. I will come >>> here later if the use arises when the "Code Componets" text >>> appears in the draft, when draft authors will use the necessary(?) >>> ipr attribute, if xml2rfc is used. >>> >>>> or you just want to state your unhapiness with the IPR approach >>>> in general wihtout any alternative approach the WG can take? >>> >>> I am unhappy about the licensing, not necessarily IPR. Several IPR >>> disclosures at IETF are ok with me. What bothers me right now is >>> the "BSD" licensing appearing in every draft. (search "BSD" or >>> "Code Components" in recent drafts, seems mandatory). >>> >>>> If that is the case, it is noted. >>> >>> YEs, please note I am unhappy with the boilerplate saying "Code >>> Components extracted from this document... BSD". Especially when it >>> tags the drafts to which I may have commented technically. >>> >>>> If not, please propose what would be your alternative approach >>>> and see if we can do it. >>> >>> WEll, each draft - prefix delegation, rfc3775bis - may need a >>> different licensing approach; the main idea would be to give >>> freedom to the implementer to tag the license s/he wants, not >>> necessarily BSD. This was the case in the past, prior to the most >>> recent boilerplate. >>> >>> (sorry when I try to discuss this many strange things happen like >>> automatically getting subscribed to -honest, bounces from trustees, >>> and more, I must be very careful). >>> >>> Thanks, >>> >>> Alex >>> >>> >>>> >>>> Regards, marcelo >>>> >>>> >>>>> (i.e. if you use ipr attribute "trust200902" in xml, if >>>>> xml2rfc is used). I do not agree with the statement "Code >>>>> Components extracted from this document... BSD license". >>>>> >>>>> I am doing so because I think I may have made technical >>>>> remarks on these drafts, in the past, but now I realize the >>>>> new licensing scheme ("trust200902") may not suit me well. >>>>> >>>>> End of statement, it's here posted in MEXT, thanks. >>>>> >>>>> Alex >>>>> >>>>> _______________________________________________ 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 marcelo@it.uc3m.es Mon Feb 22 10:31:48 2010 Return-Path: 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 7F15C28C305 for ; Mon, 22 Feb 2010 10:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.256 X-Spam-Level: X-Spam-Status: No, score=-106.256 tagged_above=-999 required=5 tests=[AWL=0.343, 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 hJb9Zec3uJGc for ; Mon, 22 Feb 2010 10:31:47 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id B182B28C30A for ; Mon, 22 Feb 2010 10:31:44 -0800 (PST) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (192.30.18.95.dynamic.jazztel.es [95.18.30.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id BFBF6BAAE92 for ; Mon, 22 Feb 2010 19:33:42 +0100 (CET) Message-ID: <4B82CE06.10100@it.uc3m.es> Date: Mon, 22 Feb 2010 19:33:42 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Subject: [MEXT] call for presentation for the next 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: , X-List-Received-Date: Mon, 22 Feb 2010 18:31:48 -0000 Hi, we are meeting in anaheim, so if you want to have a slot to present something, please send us an email (preferably, answering this one) Regards, marcelo From trac@tools.ietf.org Wed Feb 24 15:56:43 2010 Return-Path: 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 7B5D828C278 for ; Wed, 24 Feb 2010 15:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 lzmyJiEO6lfj for ; Wed, 24 Feb 2010 15:56:42 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CF23028C270 for ; Wed, 24 Feb 2010 15:56:42 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NkR7x-0002pH-II; Wed, 24 Feb 2010 15:58:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mext Issue Tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: charliep@computer.org X-Trac-Project: mext Date: Wed, 24 Feb 2010 23:58:49 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/mext/trac/ticket/18#comment:4 Message-ID: <066.ce067d9995fce5526005060bfe79244b@tools.ietf.org> References: <057.593245298a70f232e7c46117adba47bb@tools.ietf.org> X-Trac-Ticket-ID: 18 In-Reply-To: <057.593245298a70f232e7c46117adba47bb@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: mext@ietf.org Subject: Re: [MEXT] [mext] #18: Subject: Issues regarding Home Address Option & ICMP / Binding errors X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Reply-To: mext@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 23:56:43 -0000 #18: Subject: Issues regarding Home Address Option & ICMP / Binding errors ----------------------------------------+----------------------------------- Reporter: f1mauchl@… | Owner: charliep@… Type: defect | Status: closed Priority: minor | Milestone: IETF75 Component: draft-ietf-mext-rfc3775bis | Version: 4.0 Severity: Active WG Document | Resolution: fixed Keywords: ICMP Parameter Problem | ----------------------------------------+----------------------------------- Changes (by charliep@…): * status: reopened => closed * resolution: => fixed -- Ticket URL: mext From trac@tools.ietf.org Wed Feb 24 15:59:15 2010 Return-Path: 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 28AB328C28F for ; Wed, 24 Feb 2010 15:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 yeG+1jQ5Aa2Z for ; Wed, 24 Feb 2010 15:59:14 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 75C1D28C290 for ; Wed, 24 Feb 2010 15:59:14 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NkRAN-0002rJ-Eh; Wed, 24 Feb 2010 16:01:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mext Issue Tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: charliep@computer.org, julien.ietf@laposte.net X-Trac-Project: mext Date: Thu, 25 Feb 2010 00:01:19 -0000 X-URL: http://tools.ietf.org/wg/mext/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/mext/trac/ticket/7#comment:2 Message-ID: <072.45fa47b77e503dc5d19902b97c9302f9@tools.ietf.org> References: <063.eee1db399c39efaaf5a50a65984c5bdf@tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <063.eee1db399c39efaaf5a50a65984c5bdf@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: charliep@computer.org, julien.ietf@laposte.net, tero.kauppinen@ericsson.com, mext@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: tero.kauppinen@ericsson.com, mext@ietf.org Subject: Re: [MEXT] [mext] #7: DSMIPv6 BU format and RFC 3775 [Tero Kauppinen ] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Reply-To: mext@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 23:59:15 -0000 #7: DSMIPv6 BU format and RFC 3775 [Tero Kauppinen ] ----------------------------------------+----------------------------------- Reporter: charliep@… | Owner: charliep@… Type: enhancement | Status: closed Priority: minor | Milestone: Component: draft-ietf-mext-rfc3775bis | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ----------------------------------------+----------------------------------- Changes (by charliep@…): * status: new => closed * resolution: => fixed -- Ticket URL: mext From charles.perkins@earthlink.net Wed Feb 24 16:02:24 2010 Return-Path: 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 8B7FE28C297 for ; Wed, 24 Feb 2010 16:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 bcj7rmwR64PH for ; Wed, 24 Feb 2010 16:02:24 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id E1CD328C294 for ; Wed, 24 Feb 2010 16:02:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ISm0JUFx7bY3gSLKei1iyQjVtUTZrRpm2baMgPYEIcL8uSiJLKhX++xuNUKauogE; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.12]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1NkRDT-0003q4-1b for mext@ietf.org; Wed, 24 Feb 2010 19:04:31 -0500 Message-ID: <4B85BE8D.3020906@earthlink.net> Date: Wed, 24 Feb 2010 16:04:29 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f526141e727e9c0fd304b5dcc3f0c53f66a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Subject: [MEXT] rfc3775bis remaining issues #7 and #18 closed 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: , X-List-Received-Date: Thu, 25 Feb 2010 00:02:24 -0000 Hello folks, Recently, I reviewed the remaining open issues and determined that they should have been closed a long time ago. The texts for the resolution of the two issues have already been incorporated in the revision for rfc3775bis which was sent out last fall. I have closed the two remaning issues in the issue tracker, since no one has raised any objections. Unless some new issue arises, perhaps rfc3775bis is "done" for a while and ready to be submitted for consideration by the IESG. Regards, Charlie P. From julienl@qualcomm.com Thu Feb 25 08:09:43 2010 Return-Path: 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 93BA43A86DA for ; Thu, 25 Feb 2010 08:09:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.235 X-Spam-Level: X-Spam-Status: No, score=-106.235 tagged_above=-999 required=5 tests=[AWL=0.364, 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 DtkJRYuZ2ifO for ; Thu, 25 Feb 2010 08:09:42 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 889EE3A86D6 for ; Thu, 25 Feb 2010 08:09:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1267114314; x=1298650314; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"Charles=20E.=20Perkins"=20,=20mext=20|Date:=20Thu,=2025=20Fe b=202010=2008:11:51=20-0800|Subject:=20RE:=20[MEXT]=20rfc 3775bis=20remaining=20issues=20#7=20and=20#18=20closed |Thread-Topic:=20[MEXT]=20rfc3775bis=20remaining=20issues =20#7=20and=20#18=20closed|Thread-Index:=20Acq1rh6WV8zvsL VCSdW0rduahbDVwAAhvRWA|Message-ID:=20 |References:=20<4B85BE8D.3020906@earthlink.net> |In-Reply-To:=20<4B85BE8D.3020906@earthlink.net> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=0U1cOSwgViJVyj7WkVgub7Y/4NoKCG+HRjnjqwuf+Ns=; b=eNw2oczt+Ab24LWK+D12ahrxDf/DOAAPxcgmZvrRMiaSG1+PAU1gB/T7 bhwEf9J4UHcMpLj63hLzHxbQFCorhHqHHfbEs8sM+99zyfxRacMIMYfp1 3+NYejwc9T5c9VNxVjeo2bOy74oIGrTfP1pZ92BX5CdfVZQDw1IwarRE+ 8=; X-IronPort-AV: E=McAfee;i="5400,1158,5902"; a="34859419" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP; 25 Feb 2010 08:11:53 -0800 Received: from ironstorm.qualcomm.com (ironstorm.qualcomm.com [172.30.39.153]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o1PGBrMN015540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 25 Feb 2010 08:11:53 -0800 X-IronPort-AV: E=Sophos;i="4.49,539,1262592000"; d="scan'208";a="47034135" Received: from nasanexhub03.na.qualcomm.com ([10.46.93.98]) by ironstorm.qualcomm.com with ESMTP/TLS/RC4-MD5; 25 Feb 2010 08:11:53 -0800 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.234.1; Thu, 25 Feb 2010 08:11:53 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Thu, 25 Feb 2010 08:11:53 -0800 From: "Laganier, Julien" To: "Charles E. Perkins" , mext Date: Thu, 25 Feb 2010 08:11:51 -0800 Thread-Topic: [MEXT] rfc3775bis remaining issues #7 and #18 closed Thread-Index: Acq1rh6WV8zvsLVCSdW0rduahbDVwAAhvRWA Message-ID: References: <4B85BE8D.3020906@earthlink.net> In-Reply-To: <4B85BE8D.3020906@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MEXT] rfc3775bis remaining issues #7 and #18 closed 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: , X-List-Received-Date: Thu, 25 Feb 2010 16:09:43 -0000 Thanks Charlie for your hard work on this. I am going to work on the I-D wr= ite-up and request publication soon. --julien > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Charles E. Perkins > Sent: Wednesday, February 24, 2010 4:04 PM > To: mext > Subject: [MEXT] rfc3775bis remaining issues #7 and #18 closed >=20 >=20 > Hello folks, >=20 > Recently, I reviewed the remaining open issues > and determined that they should have been closed > a long time ago. The texts for the resolution > of the two issues have already been incorporated > in the revision for rfc3775bis which was sent > out last fall. >=20 > I have closed the two remaning issues in the > issue tracker, since no one has raised any > objections. >=20 > Unless some new issue arises, perhaps > rfc3775bis is "done" for a while and ready > to be submitted for consideration by the > IESG. >=20 > Regards, > Charlie P. >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From jari.arkko@piuha.net Thu Feb 25 14:18:24 2010 Return-Path: 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 03DBB3A8726 for ; Thu, 25 Feb 2010 14:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.695 X-Spam-Level: X-Spam-Status: No, score=-1.695 tagged_above=-999 required=5 tests=[AWL=-0.554, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 8QnK7C24bQGu for ; Thu, 25 Feb 2010 14:18:23 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 0BD423A872B for ; Thu, 25 Feb 2010 14:18:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id CB27E2D287; Fri, 26 Feb 2010 00:20:34 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G85CDz5+MdTK; Fri, 26 Feb 2010 00:20:34 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 1B7882CF4B; Fri, 26 Feb 2010 00:20:34 +0200 (EET) Message-ID: <4B86F7AE.1000103@piuha.net> Date: Fri, 26 Feb 2010 00:20:30 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: draft-ietf-mext-binary-ts@tools.ietf.org, "mext@ietf.org" Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [MEXT] AD review of draft-ietf-mext-binary-ts 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: , X-List-Received-Date: Thu, 25 Feb 2010 22:18:24 -0000 I have reviewed this document. It is in good shape and I have sent it forward to IETF Last Call. There were two small issues, however, and it would be helpful if you addressed them in a new document revision. Feel free to update the draft during IETF Last Call.

   (E)Start SPI - Security Parameter Index

      This field identifies the first 32-bit SPI value, from the range
      of SPI values to be matched, on data packets sent from a
      corresponding node to the mobile node as seen by the home agent.
      This field is defined in [RFC4303].

You should indicate that you are talking about *IPsec* SPIs. There are other kinds, too.


3.2.  IPv6 binary traffic selector
...
   (M)Start DS - Differential Services

      This field identifies the first differential services value, from
      the range of differential services values to be matched, on data
      packets sent from a corresponding node to the mobile node as seen
      by the home agent.  Note that this field is called Type of Service
      field in [RFC0791].  [RFC3260] then clarified that the field has
      been redefined as 6 bits DS field and 2 bits reserved, later
      claimed by Explicit Congestion Notification (ECN) [RFC3168].  For
      the purpose of this specification the DS field is 8 bits long,
      were the 6 most significant bits indicating the DS field to be
      matched and the 2 least significant bits MUST be set to 0 by the
      sender and ignored by the receiver.
The reference should be to 2460, not 0791. And RFC 2460 calls this field Traffic Class.

Jari

From wwwrun@core3.amsl.com Thu Feb 25 14:37:45 2010 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 0624528C14A; Thu, 25 Feb 2010 14:37:44 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100225223745.0624528C14A@core3.amsl.com> Date: Thu, 25 Feb 2010 14:37:45 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] Last Call: draft-ietf-mext-binary-ts (Traffic Selectors for Flow Bindings) to Proposed Standard X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 22:37:45 -0000 The IESG has received a request from the Mobility EXTensions for IPv6 WG (mext) to consider the following document: - 'Traffic Selectors for Flow Bindings ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-03-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mext-binary-ts-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18968&rfc_flag=0 From tsirtsis@googlemail.com Fri Feb 26 01:59:00 2010 Return-Path: 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 4616E28C144 for ; Fri, 26 Feb 2010 01:59:00 -0800 (PST) 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 sppvFaolgbIj for ; Fri, 26 Feb 2010 01:58:59 -0800 (PST) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id E7E9128C132 for ; Fri, 26 Feb 2010 01:58:58 -0800 (PST) Received: by fxm5 with SMTP id 5so7416051fxm.29 for ; Fri, 26 Feb 2010 02:01:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Yw3vKtCUi0Rnq5pyRLmZg46UCDkInsm/Xz3gHO9gBW8=; b=Oa6uueJ+sSnaaTGoRB2j+MizTAaG/TaX8nWOZuPgMIMsr7AuBaWvtU2MPZQQT/swia 0YeHaY7q9h8IdO14er8fLBp7UmLPzKdkGT6x6y8R72oDd2VubOLOLy4ehxVbhwvss5wr nVFxgUTZHlZlnChEvGB7KoLPHw8npwYdJkBRc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JS0WrnUbEp5Okp7mN309y9/6wSA8JeyZV4vLv6J/oHO+0qVWvbbYnr8Skv+Vo3qsDD DwF63x5JuddHip57+gve15tmO1RPpTBEfPGYWqDekX0N9VaoXe7mqf8g5OU3Wyjhmhm6 CkImtQDZao76zx804uvC+tl5cKEPz2TzenMkw= MIME-Version: 1.0 Received: by 10.239.192.65 with SMTP id d1mr11411hbi.197.1267178468244; Fri, 26 Feb 2010 02:01:08 -0800 (PST) In-Reply-To: <4B86F7AE.1000103@piuha.net> References: <4B86F7AE.1000103@piuha.net> Date: Fri, 26 Feb 2010 10:01:08 +0000 Message-ID: From: George Tsirtsis To: Jari Arkko Content-Type: text/plain; charset=UTF-8 Cc: draft-ietf-mext-binary-ts@tools.ietf.org, "mext@ietf.org" Subject: Re: [MEXT] AD review of draft-ietf-mext-binary-ts 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: , X-List-Received-Date: Fri, 26 Feb 2010 09:59:00 -0000 Hi Jari, I just posted a new version dealing with the two issues below. Thanks George On Thu, Feb 25, 2010 at 10:20 PM, Jari Arkko wrote: > I have reviewed this document. It is in good shape and I have sent it > forward to IETF Last Call. There were two small issues, however, and it > would be helpful if you addressed them in a new document revision. Feel free > to update the draft during IETF Last Call. > > (E)Start SPI - Security Parameter Index > > This field identifies the first 32-bit SPI value, from the range > of SPI values to be matched, on data packets sent from a > corresponding node to the mobile node as seen by the home agent. > This field is defined in [RFC4303]. > > > You should indicate that you are talking about *IPsec* SPIs. There are other > kinds, too. > > > 3.2. IPv6 binary traffic selector > > ... > > (M)Start DS - Differential Services > > This field identifies the first differential services value, from > the range of differential services values to be matched, on data > packets sent from a corresponding node to the mobile node as seen > by the home agent. Note that this field is called Type of Service > field in [RFC0791]. [RFC3260] then clarified that the field has > been redefined as 6 bits DS field and 2 bits reserved, later > claimed by Explicit Congestion Notification (ECN) [RFC3168]. For > the purpose of this specification the DS field is 8 bits long, > were the 6 most significant bits indicating the DS field to be > matched and the 2 least significant bits MUST be set to 0 by the > sender and ignored by the receiver. > > > The reference should be to 2460, not 0791. And RFC 2460 calls this field > Traffic Class. > > Jari > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > From root@core3.amsl.com Fri Feb 26 02:00:02 2010 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 049F928C141; Fri, 26 Feb 2010 02:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100226100002.049F928C141@core3.amsl.com> Date: Fri, 26 Feb 2010 02:00:01 -0800 (PST) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-binary-ts-04.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: , X-List-Received-Date: Fri, 26 Feb 2010 10:00:02 -0000 --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 : Traffic Selectors for Flow Bindings Author(s) : G. Tsirtsis, et al. Filename : draft-ietf-mext-binary-ts-04.txt Pages : 19 Date : 2010-02-26 This document defines binary formats for IPv4 and IPv6 traffic selectors to be used in conjunction with flow bindings for Mobile IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-binary-ts-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. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-binary-ts-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-26015740.I-D@ietf.org> --NextPart-- From jari.arkko@piuha.net Fri Feb 26 03:57:44 2010 Return-Path: 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 36A3E3A86DD for ; Fri, 26 Feb 2010 03:57:44 -0800 (PST) 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.573, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 BaMLXk93LgBJ for ; Fri, 26 Feb 2010 03:57:42 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by core3.amsl.com (Postfix) with ESMTP id 15ED43A8351 for ; Fri, 26 Feb 2010 03:57:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 0B0392D285; Fri, 26 Feb 2010 13:59:24 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RInTtwzypiu; Fri, 26 Feb 2010 13:59:23 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 2FFBB2D257; Fri, 26 Feb 2010 13:59:23 +0200 (EET) Message-ID: <4B87B797.7030206@piuha.net> Date: Fri, 26 Feb 2010 13:59:19 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: draft-ietf-mext-flow-binding@tools.ietf.org, "mext@ietf.org" Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [MEXT] AD review of draft-ietf-mext-flow-binding 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: , X-List-Received-Date: Fri, 26 Feb 2010 11:57:44 -0000 I have reviewed this specification. It is basically in very good shape, but I did detect a few small issues. Please correct them so that I can last call the document:

Mobile nodes supporting this specification MUST use the BID option
format defined in Section 4.1.  Mobile nodes MUST also register all
care-of addresses using the updated BID option format, either in the
same BU as any flow identification mobility options using them, or in
earlier BUs.
Can you talk about what the backwards compatibility issues with the additional PRI field are somewhere? I am assuming that 0 in a reserved field is ignored, and new nodes will treat PRI 0 as a sign that its an old format BID option.

When a valid binding update is received, any registered FIDs that are
not explicitly referred to in a flow identification mobility option
or in a flow summary mobility option, MUST be removed from the list
of flow binding entries for the mobile node.

Presumably this only needs to be done if the FIDs are not used by this Binding Update or any other binding that is currently in effect.

         3-250 unassigned and available for allocation based on STD
         action
Not an RFC 5226 term. Use "Standards Action" and use a reference.

         251-255 reserved for experimental use

Add some language somewhere to discuss what experimental use is appropriate. You can use RFC 5494 Section 4 as a template for this text.

STD action

Please make all of these Standards Action or IESG Approval. The latter is needed as a special case to allow judgment calls to allocate for specific needs. E.g., experimental RFCs.

      5) New "Traffic Selector Format" namespace for the Traffic
      Selector sub-option.  The traffic selector format space is defined
      by the TS Format field in Figure 5.  The following values are
      defined in this specification:

         0 Reserved

         1-250 unassigned and available for allocation based on STD
         action

         251-255 reserved for experimental use

   Similar to the procedures specified for Mobile IPv6 [RFC3775] number
   spaces, future allocations from the new number spaces requires Expert
   Review as defined i [RFC5226].
Inconsistency. Is the rule standards action, or expert review?

Missing discussions: the document is silent on MTU considerations of constructing large filter sets. Please include a new section that talks about this issue, and provides practical guidance on what types of binding update messages are still expected to work well in practice.

Jari