From Adrian.Farrel@huawei.com Wed Mar 2 01:29:16 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AA823A683D; Wed, 2 Mar 2011 01:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.442 X-Spam-Level: X-Spam-Status: No, score=-105.442 tagged_above=-999 required=5 tests=[AWL=1.157, 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 TujvafEbEntc; Wed, 2 Mar 2011 01:29:15 -0800 (PST) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id B82C63A6805; Wed, 2 Mar 2011 01:29:15 -0800 (PST) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHF00DRIBQK1Y@usaga03-in.huawei.com>; Wed, 02 Mar 2011 03:30:20 -0600 (CST) Received: from 950129200 (AGrenoble-551-1-71-24.w83-197.abo.wanadoo.fr [83.197.86.24]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LHF00H8TBQF6E@usaga03-in.huawei.com>; Wed, 02 Mar 2011 03:30:20 -0600 (CST) Date: Wed, 02 Mar 2011 10:30:20 +0000 From: Adrian Farrel To: rtg-chairs@ietf.org, rtg-dir@ietf.org, routing-discussion@ietf.org Message-id: <03b401cbd8c4$d79a62c0$86cf2840$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: AcvYxM4xNMPcyklxSICuI3R8f1zJ7A== Subject: [RTG-DIR] Routing Area Office Hours in Prague X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 09:29:16 -0000 Hi, Stewart and I have booked the IESG break-out room in Prague on Sunday afternoon 2pm to 4pm for Routing Area Office Hours. You are all very welcome to drop by and tell us what is on your mind(s). Adrian From denghui02@hotmail.com Wed Mar 9 13:26:32 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D905C3A6AB0 for ; Wed, 9 Mar 2011 13:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=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 BWUihnpgaKx3 for ; Wed, 9 Mar 2011 13:26:31 -0800 (PST) Received: from col0-omc4-s4.col0.hotmail.com (col0-omc4-s4.col0.hotmail.com [65.55.34.206]) by core3.amsl.com (Postfix) with ESMTP id 657E83A63D2 for ; Wed, 9 Mar 2011 13:26:31 -0800 (PST) Received: from COL118-W62 ([65.55.34.201]) by col0-omc4-s4.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Mar 2011 13:27:48 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_d5d30757-987f-4c63-9314-de7c77e4c60c_" X-Originating-IP: [12.198.177.31] From: Hui Deng To: , , Date: Thu, 10 Mar 2011 05:27:47 +0800 Importance: Normal In-Reply-To: <22B64EC5-E934-419C-ADC9-18A40E8ACFE1@ericsson.com> References: <4D2F8EAA.7060908@joelhalpern.com>, <059a01cbb37d$33bbf130$9b33d390$@huawei.com>, <22B64EC5-E934-419C-ADC9-18A40E8ACFE1@ericsson.com> MIME-Version: 1.0 X-OriginalArrivalTime: 09 Mar 2011 21:27:48.0181 (UTC) FILETIME=[D64EC050:01CBDEA0] X-Mailman-Approved-At: Fri, 11 Mar 2011 08:09:32 -0800 Cc: draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org, rtg-dir@ietf.org, jmh@joelhalpern.com, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 21:26:33 -0000 --_d5d30757-987f-4c63-9314-de7c77e4c60c_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hi Adrian, all Could we meet together during the coming IETF meeting about this issue, please feel free to propose your available time? Thanks a lot -Hui > From: acee.lindem@ericsson.com > To: Adrian.Farrel@huawei.com > CC: rtg-ads@tools.ietf.org; draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org; rtg-dir@ietf.org; jmh@joelhalpern.com > Date: Thu, 10 Feb 2011 13:27:29 -0500 > Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt > > Hi Joel, Adrian, > > Let me be devil's advocate - since RFC 3442 provides similar function for IPv4, why would we want to do more ask for an similar applicability and scaling caveats? > > Thanks, > Acee > On Jan 13, 2011, at 6:54 PM, Adrian Farrel wrote: > > > Hi, > > > > Of course, the I-D is not in WG last call and has, in fact, only just been > > adopted by the WG, but I asked for an early Routing Directorate review because > > the Abstract of the I-D worried me. > > > > Can we (authors, WG chairs, ADs, and Routing Directorate) have a discussion > > about the question Joel asks, and see whether this idea constitutes "dynamic > > configuration of static routes on a host" or something more scary? > > > > Many thanks, > > Adrian > > > >> -----Original Message----- > >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >> Sent: 13 January 2011 23:46 > >> To: rtg-ads@tools.ietf.org > >> Cc: rtg-dir@ietf.org; draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org > >> Subject: RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt > >> > >> Hello, > >> > >> I have been selected as the Routing Directorate reviewer for this draft. > >> The Routing Directorate seeks to review all routing or routing-related > >> drafts as they pass through IETF last call and IESG review. The purpose > >> of the review is to provide assistance to the Routing ADs. For more > >> information about the Routing Directorate, please see > >> http://www.ietf.org/iesg/directorate/routing.html > >> > >> Although these comments are primarily for the use of the Routing ADs, it > >> would be helpful if you could consider them along with any other IETF > >> Last Call comments that you receive, and strive to resolve them through > >> discussion or by updating the draft. > >> > >> Document: draft-ietf-mif-dhcpv6-route-option-00.txt > >> Reviewer: Joel M. Halpern > >> Review Date: 13-Jan-2011 > >> IETF LC End Date: N/A > >> Intended Status: Standards Track > >> > >> Summary: I have significant concerns about this document and recommend > >> that the Routing ADs discuss these issues further with the authors. > >> > >> Comments: > >> > >> Major Issues: > >> Given the existence of RFC 3442, I will not investigate the > >> question of whether this is a sensible strategy for directing hosts. I > >> do understand that there are good reasons for wanting to do this. > >> However, it seems to me that there needs to be a discussion of how this > >> will be made consistent with routing. A configured preference of this > >> sort could easily cause a host to send messages into a long-lived > >> temporary black hole, even when there is another path. Is there an > >> expectation that this will somehow be synchronized with teh routing > >> system? If so, how? If not, what are the consequences if things get > >> de-synchronized. > >> > >> Minor Issues: > >> I presume that the reason there is no discussion of size issues, as > >> there is in RFC 3442, is due to some difference in DHCPv6 vs DHCPv4? It > >> would seem that even if this is a non-issue, this document should say > >> why it is a non-issue. (It seems likely that excessive use of this > >> option by an administrator could cause difficulties.) > >> > >> Nits: > >> The introduction begins with the phrasing "The Neighbor Discovery > >> (ICMPv6) protocol". While ND rides on top of ICMPv6, it is not the same > >> as ICMPv6. The parenthetical is misleading rather than helpful. Please > >> remove it. > >> In contrast, it would be helpful if the beginning of the next > >> sentence, "Extensions to the protocol defined in [RFC4191]" actually > >> included the words "Router Advertisement" in the text, since that is > >> what protocol is referred to without being named. > >> > >> It would seem a good idea to include a reference to the current > >> specification of DHCPv6 the first time it is mentioned. > >> > >> It would be clearer (not technically different, but clearer) if the > >> first and second sentence in section 4 each indicated what message > >> (presumably request and response respectively) is being used to carry > >> this information. Even if obvious, it would also be good if the second > >> sentence referred to whatever option holder the response message uses, > >> in parallel with the construction of the first sentence. > >> > >> The text in section 4.1 as written makes it appear that routes are > >> sent individually, rather than the description of the first part of > >> section 4 or the actual description of the format of the > >> OPTION_NEXT_HOP. (As written in 4.1, one is led to expect pairs of > >> next-hops and routes, which is clearly not what you actually intend.) > >> > >> Yours, > >> Joel M. Halpern > > > --_d5d30757-987f-4c63-9314-de7c77e4c60c_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Hi Adrian, all
 
Could we meet together during the coming IETF meeting about this issue,
please feel free to propose your available time?
 
Thanks a lot
 
-Hui
 
> From: acee.lindem@ericsson.com
> To: Adrian.Farrel@huawei.com
> CC: rtg-ads@tools.ietf.org; draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org; rtg-dir@ietf.org; jmh@joelhalpern.com
> Date: Thu, 10 Feb 2011 13:27:29 -0500
> Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt
>
> Hi Joel, Adrian,
>
> Let me be devil's advocate - since RFC 3442 provides similar function for IPv4, why would we want to do more ask for an similar applicability and scaling caveats?
>
> Thanks,
> Acee
> On Jan 13, 2011, at 6:54 PM, Adrian Farrel wrote:
>
> > Hi,
> >
> > Of course, the I-D is not in WG last call and has, in fact, only just been
> > adopted by the WG, but I asked for an early Routing Directorate review because
> > the Abstract of the I-D worried me.
> >
> > Can we (authors, WG chairs, ADs, and Routing D irectorate) have a discussion
> > about the question Joel asks, and see whether this idea constitutes "dynamic
> > configuration of static routes on a host" or something more scary?
> >
> > Many thanks,
> > Adrian
> >
> >> -----Original Message-----
> >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> >> Sent: 13 January 2011 23:46
> >> To: rtg-ads@tools.ietf.org
> >> Cc: rtg-dir@ietf.org; draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org
> >> Subject: RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt
> >>
> >> Hello,
> >>
> >> I have been selected as the Routing Directorate reviewer for this draft.
> >> The Routing Directorate seeks to review all routing or routing-related
> >> drafts as they pass through IETF last call and IESG review. The purpose
> > ;> of the review is to provide assistance to the Routing ADs. For more
> >> information about the Routing Directorate, please see
> >> http://www.ietf.org/iesg/directorate/routing.html
> >>
> >> Although these comments are primarily for the use of the Routing ADs, it
> >> would be helpful if you could consider them along with any other IETF
> >> Last Call comments that you receive, and strive to resolve them through
> >> discussion or by updating the draft.
> >>
> >> Document: draft-ietf-mif-dhcpv6-route-option-00.txt
> >> Reviewer: Joel M. Halpern
> >> Review Date: 13-Jan-2011
> >> IETF LC End Date: N/A
> >> Intended Status: Standards Track
> >>
> >> Summary: I have significant concerns about this document and recommend
> >> that the Routing ADs discuss these issues further with the authors.
> >>
> >> Comments:
> >>
> >> Major Issues:
> >> Given the existence of RFC 3442, I will not investigate the
> >> question of whether this is a sensible strategy for directing hosts. I
> >> do understand that there are good reasons for wanting to do this.
> >> However, it seems to me that there needs to be a discussion of how this
> >> will be made consistent with routing. A configured preference of this
> >> sort could easily cause a host to send messages into a long-lived
> >> temporary black hole, even when there is another path. Is there an
> >> expectation that this will somehow be synchronized with teh routing
> >> system? If so, how? If not, what are the consequences if things get
> >> de-synchronized.
> >>
> >> Minor Issues:
> >> I presume that the re ason there is no discussion of size issues, as
> >> there is in RFC 3442, is due to some difference in DHCPv6 vs DHCPv4? It
> >> would seem that even if this is a non-issue, this document should say
> >> why it is a non-issue. (It seems likely that excessive use of this
> >> option by an administrator could cause difficulties.)
> >>
> >> Nits:
> >> The introduction begins with the phrasing "The Neighbor Discovery
> >> (ICMPv6) protocol". While ND rides on top of ICMPv6, it is not the same
> >> as ICMPv6. The parenthetical is misleading rather than helpful. Please
> >> remove it.
> >> In contrast, it would be helpful if the beginning of the next
> >> sentence, "Extensions to the protocol defined in [RFC4191]" actually
> >> included the words "Router Advertisement" in the text, since that is
> >> what protocol is referred to without being named.
> >>
> >> It would seem a good idea to include a reference to the current
> >> specification of DHCPv6 the first time it is mentioned.
> >>
> >> It would be clearer (not technically different, but clearer) if the
> >> first and second sentence in section 4 each indicated what message
> >> (presumably request and response respectively) is being used to carry
> >> this information. Even if obvious, it would also be good if the second
> >> sentence referred to whatever option holder the response message uses,
> >> in parallel with the construction of the first sentence.
> >>
> >> The text in section 4.1 as written makes it appear that routes are
> >> sent individually, rather than the description of the first part of
> >> section 4 or the actual description of the format of the
> >> OPTION_NEXT_HOP. (As written in 4.1, one is led to expect pairs of
> >> next-hops and routes, which is clearly not what you actually intend.)
> >>
> >> Yours,
> >> Joel M. Halpern
> >
>
--_d5d30757-987f-4c63-9314-de7c77e4c60c_-- From tomasz.mrugalski@gmail.com Mon Mar 14 02:32:23 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA5FF3A6C5F for ; Mon, 14 Mar 2011 02:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 XSE51jBdEsqF for ; Mon, 14 Mar 2011 02:32:23 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id F3C903A6853 for ; Mon, 14 Mar 2011 02:32:22 -0700 (PDT) Received: by eye13 with SMTP id 13so1863253eye.31 for ; Mon, 14 Mar 2011 02:33:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Py9WulG7EP6tq1YXOPEJgzKS2cXYiTB3DrtUWmvbkUI=; b=RoaUc2IX8AqIbP2T/Xjg3I9UzBxXeT1ZrS7Y/QzBEQ2qddiZnig65B06aVKVimaZwk U4MK9dHsg/sVRrS8jDFM2boNP3vgxlNGZuS66mNqoURtu4stwpJa0QLIA3lSBEn7TJ6e Vf99fDLHg0mfI4pHR+aL/la/GicGPANLZiDes= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=vFBLCdg34fe0A/cS8WEVoltEnjifYxSEfE7YX0eYAbOZ0+AxWPTX0Ws6fHDcVauPIt BUfsmkNUfuymeydQVKIpfkX7Fub9kV0po0WRd271Mpi9zUGB9BA2EOjSMxnkqFy2Cz44 mztCr3HiEtWeSR29FHIKjkYf6oz7A3KMfFMz0= Received: by 10.213.16.72 with SMTP id n8mr1269934eba.12.1300095225066; Mon, 14 Mar 2011 02:33:45 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl [109.107.11.157]) by mx.google.com with ESMTPS id w59sm5751807eeh.21.2011.03.14.02.33.42 (version=SSLv3 cipher=OTHER); Mon, 14 Mar 2011 02:33:42 -0700 (PDT) Message-ID: <4D7DE0EC.5010903@gmail.com> Date: Mon, 14 Mar 2011 10:33:32 +0100 From: Tomasz Mrugalski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Hui Deng References: <4D2F8EAA.7060908@joelhalpern.com>, <059a01cbb37d$33bbf130$9b33d390$@huawei.com>, <22B64EC5-E934-419C-ADC9-18A40E8ACFE1@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 15 Mar 2011 08:12:52 -0700 Cc: rtg-dir@ietf.org, wdec.ietf@gmail.com, draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org, acee.lindem@ericsson.com, adrian.farrel@huawei.com, rtg-ads@tools.ietf.org, jmh@joelhalpern.com Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 09:32:24 -0000 On 09.03.2011 22:27, Hui Deng wrote: > Hi Adrian, all > > Could we meet together during the coming IETF meeting about this issue, > please feel free to propose your available time? I'm available Sunday (March 27th) till Friday (April 1st), except Wednesday evening. See you in Prague, Tomek From tomasz.mrugalski@gmail.com Mon Mar 28 05:58:08 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDD883A6A2C for ; Mon, 28 Mar 2011 05:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 VF1llTFUfw8l for ; Mon, 28 Mar 2011 05:58:07 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 9CF753A67E4 for ; Mon, 28 Mar 2011 05:58:07 -0700 (PDT) Received: by pwi5 with SMTP id 5so709814pwi.31 for ; Mon, 28 Mar 2011 05:59:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=sLsAD4U920GPNdtqEtDib8EDY4Tnr7xj1rC80w1ZtCE=; b=fNmzWh9GITF8idVeUDJwp4V1untRDB5aclx4D8Pi+NlhWPOGpXUKEnYkvPWE2paXEG TIEMUSTc150W/nFvZlTVg4zpsUPSpUyKaAsuxWVs8T2jM2gRSEQqX89Pk6gBMdzJBwxD tbcn5/i/UdyEVma5nHjGTboR1JexsdiFzlolw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=j5cTnX3n02VoMntpn915wqJnM/sVBbL9rXi8di6InAOba23zPgpRMDUL/xJSPkCjl8 8avdDYzHBQcVPV9B41Gg+pOrQW/nQmzIlkQn0K7a6nt32RV/WN+OyB7nzxzv5uy+r0pg d2LmQ4d6fo1KzhXfpKN7AsIULQdC7xWardToc= Received: by 10.142.136.3 with SMTP id j3mr3852125wfd.24.1301317184363; Mon, 28 Mar 2011 05:59:44 -0700 (PDT) Received: from dhcp-11aa.meeting.ietf.org (dhcp-11aa.meeting.ietf.org [130.129.17.170]) by mx.google.com with ESMTPS id m10sm5858762wfl.11.2011.03.28.05.59.39 (version=SSLv3 cipher=OTHER); Mon, 28 Mar 2011 05:59:42 -0700 (PDT) Message-ID: <4D908639.906@gmail.com> Date: Mon, 28 Mar 2011 14:59:37 +0200 From: Tomasz Mrugalski User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Hui Deng References: <4D2F8EAA.7060908@joelhalpern.com>, <059a01cbb37d$33bbf130$9b33d390$@huawei.com>, <22B64EC5-E934-419C-ADC9-18A40E8ACFE1@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 28 Mar 2011 07:05:35 -0700 Cc: rtg-dir@ietf.org, wdec.ietf@gmail.com, draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org, acee.lindem@ericsson.com, adrian.farrel@huawei.com, rtg-ads@tools.ietf.org, jmh@joelhalpern.com Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 12:58:09 -0000 On 11-03-09 22:27, Hui Deng wrote: > Hi Adrian, all > > Could we meet together during the coming IETF meeting about this issue, > please feel free to propose your available time? Are we planning to meet? If that is so, I'm available *except* following times: Tuesday 900-1100 Wednesday 900-1130, 19 or later Thursday 1300-1500 Tomek >> From: acee.lindem@ericsson.com >> To: Adrian.Farrel@huawei.com >> CC: rtg-ads@tools.ietf.org; > draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org; rtg-dir@ietf.org; > jmh@joelhalpern.com >> Date: Thu, 10 Feb 2011 13:27:29 -0500 >> Subject: Re: [RTG-DIR] RtgDir review: > draft-ietf-mif-dhcpv6-route-option-00.txt >> >> Hi Joel, Adrian, >> >> Let me be devil's advocate - since RFC 3442 provides similar function > for IPv4, why would we want to do more ask for an similar applicability > and scaling caveats? >> >> Thanks, >> Acee >> On Jan 13, 2011, at 6:54 PM, Adrian Farrel wrote: >> >> > Hi, >> > >> > Of course, the I-D is not in WG last call and has, in fact, only > just been >> > adopted by the WG, but I asked for an early Routing Directorate > review because >> > the Abstract of the I-D worried me. >> > >> > Can we (authors, WG chairs, ADs, and Routing D irectorate) have a > discussion >> > about the question Joel asks, and see whether this idea constitutes > "dynamic >> > configuration of static routes on a host" or something more scary? >> > >> > Many thanks, >> > Adrian >> > >> >> -----Original Message----- >> >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> >> Sent: 13 January 2011 23:46 >> >> To: rtg-ads@tools.ietf.org >> >> Cc: rtg-dir@ietf.org; > draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org >> >> Subject: RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt >> >> >> >> Hello, >> >> >> >> I have been selected as the Routing Directorate reviewer for this > draft. >> >> The Routing Directorate seeks to review all routing or routing-related >> >> drafts as they pass through IETF last call and IESG review. The purpose >> > ;> of the review is to provide assistance to the Routing ADs. For more >> >> information about the Routing Directorate, please see >> >> http://www.ietf.org/iesg/directorate/routing.html >> >> >> >> Although these comments are primarily for the use of the Routing > ADs, it >> >> would be helpful if you could consider them along with any other IETF >> >> Last Call comments that you receive, and strive to resolve them through >> >> discussion or by updating the draft. >> >> >> >> Document: draft-ietf-mif-dhcpv6-route-option-00.txt >> >> Reviewer: Joel M. Halpern >> >> Review Date: 13-Jan-2011 >> >> IETF LC End Date: N/A >> >> Intended Status: Standards Track >> >> >> >> Summary: I have significant concerns about this document and recommend >> >> that the Routing ADs discuss these issues further with the authors. >> >> >> >> Comments: >> >> >> >> Major Issues: >> >> Given the existence of RFC 3442, I will not investigate the >> >> question of whether this is a sensible strategy for directing hosts. I >> >> do understand that there are good reasons for wanting to do this. >> >> However, it seems to me that there needs to be a discussion of how this >> >> will be made consistent with routing. A configured preference of this >> >> sort could easily cause a host to send messages into a long-lived >> >> temporary black hole, even when there is another path. Is there an >> >> expectation that this will somehow be synchronized with teh routing >> >> system? If so, how? If not, what are the consequences if things get >> >> de-synchronized. >> >> >> >> Minor Issues: >> >> I presume that the re ason there is no discussion of size issues, as >> >> there is in RFC 3442, is due to some difference in DHCPv6 vs DHCPv4? It >> >> would seem that even if this is a non-issue, this document should say >> >> why it is a non-issue. (It seems likely that excessive use of this >> >> option by an administrator could cause difficulties.) >> >> >> >> Nits: >> >> The introduction begins with the phrasing "The Neighbor Discovery >> >> (ICMPv6) protocol". While ND rides on top of ICMPv6, it is not the same >> >> as ICMPv6. The parenthetical is misleading rather than helpful. Please >> >> remove it. >> >> In contrast, it would be helpful if the beginning of the next >> >> sentence, "Extensions to the protocol defined in [RFC4191]" actually >> >> included the words "Router Advertisement" in the text, since that is >> >> what protocol is referred to without being named. >> >> >> >> It would seem a good idea to include a reference to the current >> >> specification of DHCPv6 the first time it is mentioned. >> >> >> >> It would be clearer (not technically different, but clearer) if the >> >> first and second sentence in section 4 each indicated what message >> >> (presumably request and response respectively) is being used to carry >> >> this information. Even if obvious, it would also be good if the second >> >> sentence referred to whatever option holder the response message uses, >> >> in parallel with the construction of the first sentence. >> >> >> >> The text in section 4.1 as written makes it appear that routes are >> >> sent individually, rather than the description of the first part of >> >> section 4 or the actual description of the format of the >> >> OPTION_NEXT_HOP. (As written in 4.1, one is led to expect pairs of >> >> next-hops and routes, which is clearly not what you actually intend.) >> >> >> >> Yours, >> >> Joel M. Halpern >> > >> From Adrian.Farrel@huawei.com Mon Mar 28 09:13:16 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 323EE28B56A for ; Mon, 28 Mar 2011 09:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.17 X-Spam-Level: X-Spam-Status: No, score=-103.17 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, 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 kTCO5qJeL7zT for ; Mon, 28 Mar 2011 09:13:15 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id F0B803A67E5 for ; Mon, 28 Mar 2011 09:13:14 -0700 (PDT) Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIR00E9MZSRR6@usaga01-in.huawei.com> for rtg-dir@ietf.org; Mon, 28 Mar 2011 11:14:51 -0500 (CDT) Received: from 950129200 (dhcp-15a5.meeting.ietf.org [130.129.21.165]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LIR001MWZSNQ0@usaga01-in.huawei.com> for rtg-dir@ietf.org; Mon, 28 Mar 2011 11:14:51 -0500 (CDT) Date: Mon, 28 Mar 2011 18:14:47 +0200 From: Adrian Farrel In-reply-to: <4D908639.906@gmail.com> To: 'Tomasz Mrugalski' , 'Hui Deng' Message-id: <052c01cbed63$4434fe60$cc9efb20$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: AQKzeNGgyTvUlNrC6NMrNhCvH+xYUgFMGYVLAYL8XJoCEoTxMwJTcFhpkjordRA= References: <4D2F8EAA.7060908@joelhalpern.com> <059a01cbb37d$33bbf130$9b33d390$@huawei.com> <22B64EC5-E934-419C-ADC9-18A40E8ACFE1@ericsson.com> <4D908639.906@gmail.com> Cc: rtg-dir@ietf.org, wdec.ietf@gmail.com, draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org, acee.lindem@ericsson.com, rtg-ads@tools.ietf.org, jmh@joelhalpern.com Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 16:13:16 -0000 Hi, Yes, we should try to discuss this face-to-face. I would love to do this with Joel. Are you all around on Friday (I'm guessing Joel will be in Karp :-) Friday lunch or after 3pm works really well for me. Adrian > -----Original Message----- > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behalf Of > Tomasz Mrugalski > Sent: 28 March 2011 15:00 > To: Hui Deng > Cc: rtg-dir@ietf.org; wdec.ietf@gmail.com; draft-ietf-mif-dhcpv6-route- > option.all@tools.ietf.org; acee.lindem@ericsson.com; > Adrian.Farrel@huawei.com; rtg-ads@tools.ietf.org; jmh@joelhalpern.com > Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt > > On 11-03-09 22:27, Hui Deng wrote: > > Hi Adrian, all > > > > Could we meet together during the coming IETF meeting about this issue, > > please feel free to propose your available time? > Are we planning to meet? If that is so, I'm available *except* following > times: > Tuesday 900-1100 > Wednesday 900-1130, 19 or later > Thursday 1300-1500 > > Tomek > > >> From: acee.lindem@ericsson.com > >> To: Adrian.Farrel@huawei.com > >> CC: rtg-ads@tools.ietf.org; > > draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org; rtg-dir@ietf.org; > > jmh@joelhalpern.com > >> Date: Thu, 10 Feb 2011 13:27:29 -0500 > >> Subject: Re: [RTG-DIR] RtgDir review: > > draft-ietf-mif-dhcpv6-route-option-00.txt > >> > >> Hi Joel, Adrian, > >> > >> Let me be devil's advocate - since RFC 3442 provides similar function > > for IPv4, why would we want to do more ask for an similar applicability > > and scaling caveats? > >> > >> Thanks, > >> Acee > >> On Jan 13, 2011, at 6:54 PM, Adrian Farrel wrote: > >> > >> > Hi, > >> > > >> > Of course, the I-D is not in WG last call and has, in fact, only > > just been > >> > adopted by the WG, but I asked for an early Routing Directorate > > review because > >> > the Abstract of the I-D worried me. > >> > > >> > Can we (authors, WG chairs, ADs, and Routing D irectorate) have a > > discussion > >> > about the question Joel asks, and see whether this idea constitutes > > "dynamic > >> > configuration of static routes on a host" or something more scary? > >> > > >> > Many thanks, > >> > Adrian > >> > > >> >> -----Original Message----- > >> >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >> >> Sent: 13 January 2011 23:46 > >> >> To: rtg-ads@tools.ietf.org > >> >> Cc: rtg-dir@ietf.org; > > draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org > >> >> Subject: RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt > >> >> > >> >> Hello, > >> >> > >> >> I have been selected as the Routing Directorate reviewer for this > > draft. > >> >> The Routing Directorate seeks to review all routing or routing-related > >> >> drafts as they pass through IETF last call and IESG review. The purpose > >> > ;> of the review is to provide assistance to the Routing ADs. For more > >> >> information about the Routing Directorate, please see > >> >> http://www.ietf.org/iesg/directorate/routing.html > >> >> > >> >> Although these comments are primarily for the use of the Routing > > ADs, it > >> >> would be helpful if you could consider them along with any other IETF > >> >> Last Call comments that you receive, and strive to resolve them through > >> >> discussion or by updating the draft. > >> >> > >> >> Document: draft-ietf-mif-dhcpv6-route-option-00.txt > >> >> Reviewer: Joel M. Halpern > >> >> Review Date: 13-Jan-2011 > >> >> IETF LC End Date: N/A > >> >> Intended Status: Standards Track > >> >> > >> >> Summary: I have significant concerns about this document and recommend > >> >> that the Routing ADs discuss these issues further with the authors. > >> >> > >> >> Comments: > >> >> > >> >> Major Issues: > >> >> Given the existence of RFC 3442, I will not investigate the > >> >> question of whether this is a sensible strategy for directing hosts. I > >> >> do understand that there are good reasons for wanting to do this. > >> >> However, it seems to me that there needs to be a discussion of how this > >> >> will be made consistent with routing. A configured preference of this > >> >> sort could easily cause a host to send messages into a long-lived > >> >> temporary black hole, even when there is another path. Is there an > >> >> expectation that this will somehow be synchronized with teh routing > >> >> system? If so, how? If not, what are the consequences if things get > >> >> de-synchronized. > >> >> > >> >> Minor Issues: > >> >> I presume that the re ason there is no discussion of size issues, as > >> >> there is in RFC 3442, is due to some difference in DHCPv6 vs DHCPv4? It > >> >> would seem that even if this is a non-issue, this document should say > >> >> why it is a non-issue. (It seems likely that excessive use of this > >> >> option by an administrator could cause difficulties.) > >> >> > >> >> Nits: > >> >> The introduction begins with the phrasing "The Neighbor Discovery > >> >> (ICMPv6) protocol". While ND rides on top of ICMPv6, it is not the same > >> >> as ICMPv6. The parenthetical is misleading rather than helpful. Please > >> >> remove it. > >> >> In contrast, it would be helpful if the beginning of the next > >> >> sentence, "Extensions to the protocol defined in [RFC4191]" actually > >> >> included the words "Router Advertisement" in the text, since that is > >> >> what protocol is referred to without being named. > >> >> > >> >> It would seem a good idea to include a reference to the current > >> >> specification of DHCPv6 the first time it is mentioned. > >> >> > >> >> It would be clearer (not technically different, but clearer) if the > >> >> first and second sentence in section 4 each indicated what message > >> >> (presumably request and response respectively) is being used to carry > >> >> this information. Even if obvious, it would also be good if the second > >> >> sentence referred to whatever option holder the response message uses, > >> >> in parallel with the construction of the first sentence. > >> >> > >> >> The text in section 4.1 as written makes it appear that routes are > >> >> sent individually, rather than the description of the first part of > >> >> section 4 or the actual description of the format of the > >> >> OPTION_NEXT_HOP. (As written in 4.1, one is led to expect pairs of > >> >> next-hops and routes, which is clearly not what you actually intend.) > >> >> > >> >> Yours, > >> >> Joel M. Halpern > >> > > >> From behcetsarikaya@yahoo.com Mon Mar 28 09:48:55 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DF523A6842 for ; Mon, 28 Mar 2011 09:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, 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 BKA+h26wAEYa for ; Mon, 28 Mar 2011 09:48:54 -0700 (PDT) Received: from nm26-vm0.bullet.mail.sp2.yahoo.com (nm26-vm0.bullet.mail.sp2.yahoo.com [98.139.91.230]) by core3.amsl.com (Postfix) with SMTP id 7AF053A659C for ; Mon, 28 Mar 2011 09:48:54 -0700 (PDT) Received: from [98.139.91.69] by nm26.bullet.mail.sp2.yahoo.com with NNFMP; 28 Mar 2011 16:50:29 -0000 Received: from [98.139.91.2] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 28 Mar 2011 16:50:29 -0000 Received: from [127.0.0.1] by omp1002.mail.sp2.yahoo.com with NNFMP; 28 Mar 2011 16:50:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 650686.97298.bm@omp1002.mail.sp2.yahoo.com Received: (qmail 43734 invoked by uid 60001); 28 Mar 2011 16:50:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1301331029; bh=1NxW7jmTcrBGJ+3yDNoA4rmk2+XlYUqO9UWzjbESiA8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=y0OnfQHi9AoxHqy6+KEGtPPm6O9pW+yJevHQxa6RXkyTgTn/UyNm9UMzLiI7GKBtzRTFv6J9+94gdpuPTKdXGraBwtcYwja3XiUX0QFQwyUjBH29M7Yv9vEdGEDjBIgq+Bn5pG8ii2xrDHv4r9tULhPRshX+Fo/KU0wNUyO83bs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=fnkYljdJXs7H+S1pdruFhArNFylVbOQIsuKG4xEJoSq/uxtFlHq9uydUUaPiuBi/G8ASclyhQijZqfRuIWpw5IzvCfTFSXcHhQ6vmrAimZ8XqzTdlFkCHG+J5CG6l+FNjrv/R+b3OdCW/EEHTAbneejYk0WmGAZHk6V5MTtuXxY=; Message-ID: <72529.40925.qm@web111403.mail.gq1.yahoo.com> X-YMail-OSG: ZMUNI7cVM1nTFno3Go8qNNGA6lJHDxeGhr9RArE083q4MQG ykE2ocy7hI2qZHf3bgxXRBYzBCLZbcMWw7y2cw9PdMXHDg0z58G4vcKlVWs_ AJQwhsWyhQAE_xVY2SlibBftwfKj3vjvlCIHhWbqoaZ8D4hNWC5gA3uCcBA7 .ZKJYhuOa95uDq1ewCvpIk30fdJ6ijI20jHXLj.axbar7eQ50HhsI0JQkATk M_NUG7wMAG5N2ORmYOQvp_gDJRTWeCsKxuoeje98NBzenuqOoJZitgA9fC_k XbAGba6FMKGsRPJzlunbH0Px_vx1lLFB60O5Eg_x.ziMv_dPQog7QewWivnY _eevTeqXY3i49PDc40lElKpxHpliRJbtv1acXdqfGIQ6SNLxUVhuEImeA1t. reuAJwgUhdVCz Received: from [130.129.69.115] by web111403.mail.gq1.yahoo.com via HTTP; Mon, 28 Mar 2011 09:50:28 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.109.295617 References: <4D2F8EAA.7060908@joelhalpern.com> <059a01cbb37d$33bbf130$9b33d390$@huawei.com> <22B64EC5-E934-419C-ADC9-18A40E8ACFE1@ericsson.com> <4D908639.906@gmail.com> <052c01cbed63$4434fe60$cc9efb20$@huawei.com> Date: Mon, 28 Mar 2011 09:50:28 -0700 (PDT) From: Behcet Sarikaya To: Adrian.Farrel@huawei.com, Tomasz Mrugalski , Hui Deng In-Reply-To: <052c01cbed63$4434fe60$cc9efb20$@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Mon, 28 Mar 2011 09:53:05 -0700 Cc: rtg-dir@ietf.org, wdec.ietf@gmail.com, draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org, acee.lindem@ericsson.com, rtg-ads@tools.ietf.org, jmh@joelhalpern.com Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 16:48:55 -0000 > > Hi, > > Yes, we should try to discuss this face-to-face. > > I would love to do this with Joel. > Are you all around on Friday (I'm guessing Joel will be in Karp :-) > > Friday lunch or after 3pm works really well for me. +1 Behcet From tomasz.mrugalski@gmail.com Mon Mar 28 09:51:38 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46B553A6859 for ; Mon, 28 Mar 2011 09:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 qvYz+H+YglQ9 for ; Mon, 28 Mar 2011 09:51:37 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 6B02E3A67A1 for ; Mon, 28 Mar 2011 09:51:37 -0700 (PDT) Received: by pve39 with SMTP id 39so734793pve.31 for ; Mon, 28 Mar 2011 09:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Xbj9WbWHlSZrSA0pRdZAaNLdszu99r7ejZngtstN/YE=; b=I+xIMsDAHQyukQxirXQLMBWIftGtT28lQaJTOIe+GrT8PXyBGoTMvJLc2zXBczG0m9 QHeGltH6ZBd5nmX3kJAg7OQ3SPwd3vHL5Zz/lpJ3CfKh2JxfsTasv8kzNSYnalxERwHb SwGLxOXbQ85Oj/zTPc/t5FIbP6PUCceHts0bE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=VziAeJLTlEbyfIHtB2kfaaylWZjPL8AmgxP8NFd5A9ryJs9ej725MzyH+tqxricCww 3J5n1csFQPAo/18vWUrlXGnDK53tujuSJg+7kwpZW/0a1yhJZVTK/cHz0I6cwPCwC6gn mdcjv920tZLfJpYzbpHyLKUrkZsoImExkmd1Q= Received: by 10.142.112.13 with SMTP id k13mr3919415wfc.406.1301331195030; Mon, 28 Mar 2011 09:53:15 -0700 (PDT) Received: from dhcp-11aa.meeting.ietf.org (dhcp-11aa.meeting.ietf.org [130.129.17.170]) by mx.google.com with ESMTPS id p40sm6083785wfc.5.2011.03.28.09.53.11 (version=SSLv3 cipher=OTHER); Mon, 28 Mar 2011 09:53:14 -0700 (PDT) Message-ID: <4D90BCF5.5010905@gmail.com> Date: Mon, 28 Mar 2011 18:53:09 +0200 From: Tomasz Mrugalski User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Behcet Sarikaya References: <4D2F8EAA.7060908@joelhalpern.com> <059a01cbb37d$33bbf130$9b33d390$@huawei.com> <22B64EC5-E934-419C-ADC9-18A40E8ACFE1@ericsson.com> <4D908639.906@gmail.com> <052c01cbed63$4434fe60$cc9efb20$@huawei.com> <72529.40925.qm@web111403.mail.gq1.yahoo.com> In-Reply-To: <72529.40925.qm@web111403.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 28 Mar 2011 09:54:10 -0700 Cc: rtg-dir@ietf.org, wdec.ietf@gmail.com, draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org, acee.lindem@ericsson.com, Behcet Sarikaya , Adrian.Farrel@huawei.com, rtg-ads@tools.ietf.org, jmh@joelhalpern.com, Hui Deng Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 16:51:38 -0000 On 11-03-28 18:50, Behcet Sarikaya wrote: >> Hi, >> >> Yes, we should try to discuss this face-to-face. >> >> I would love to do this with Joel. >> Are you all around on Friday (I'm guessing Joel will be in Karp :-) >> >> Friday lunch or after 3pm works really well for me. > +1 > > Behcet +1 Tomek From jmh@joelhalpern.com Mon Mar 28 10:09:29 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B429028C0DC for ; Mon, 28 Mar 2011 10:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 L4lHduVciuky for ; Mon, 28 Mar 2011 10:09:28 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id 8CFF33A6842 for ; Mon, 28 Mar 2011 10:09:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6BE7743004E; Mon, 28 Mar 2011 10:11:06 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [130.129.38.181] (dhcp-26b5.meeting.ietf.org [130.129.38.181]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 7B8004300EA; Mon, 28 Mar 2011 10:11:04 -0700 (PDT) Message-ID: <4D90C124.9020102@joelhalpern.com> Date: Mon, 28 Mar 2011 13:11:00 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Adrian.Farrel@huawei.com References: <4D2F8EAA.7060908@joelhalpern.com> <059a01cbb37d$33bbf130$9b33d390$@huawei.com> <22B64EC5-E934-419C-ADC9-18A40E8ACFE1@ericsson.com> <4D908639.906@gmail.com> <052c01cbed63$4434fe60$cc9efb20$@huawei.com> In-Reply-To: <052c01cbed63$4434fe60$cc9efb20$@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, wdec.ietf@gmail.com, 'Tomasz Mrugalski' , draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org, acee.lindem@ericsson.com, rtg-ads@tools.ietf.org, 'Hui Deng' Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 17:09:29 -0000 I could squeeze out Wednesday morning. Friday morning is definitely KARP. Friday after 3 is best. Yours, Joel On 3/28/2011 12:14 PM, Adrian Farrel wrote: > Hi, > > Yes, we should try to discuss this face-to-face. > > I would love to do this with Joel. > Are you all around on Friday (I'm guessing Joel will be in Karp :-) > > Friday lunch or after 3pm works really well for me. > > Adrian > >> -----Original Message----- >> From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behalf Of >> Tomasz Mrugalski >> Sent: 28 March 2011 15:00 >> To: Hui Deng >> Cc: rtg-dir@ietf.org; wdec.ietf@gmail.com; draft-ietf-mif-dhcpv6-route- >> option.all@tools.ietf.org; acee.lindem@ericsson.com; >> Adrian.Farrel@huawei.com; rtg-ads@tools.ietf.org; jmh@joelhalpern.com >> Subject: Re: [RTG-DIR] RtgDir review: > draft-ietf-mif-dhcpv6-route-option-00.txt >> >> On 11-03-09 22:27, Hui Deng wrote: >>> Hi Adrian, all >>> >>> Could we meet together during the coming IETF meeting about this issue, >>> please feel free to propose your available time? >> Are we planning to meet? If that is so, I'm available *except* following >> times: >> Tuesday 900-1100 >> Wednesday 900-1130, 19 or later >> Thursday 1300-1500 >> >> Tomek >> >>>> From: acee.lindem@ericsson.com >>>> To: Adrian.Farrel@huawei.com >>>> CC: rtg-ads@tools.ietf.org; >>> draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org; rtg-dir@ietf.org; >>> jmh@joelhalpern.com >>>> Date: Thu, 10 Feb 2011 13:27:29 -0500 >>>> Subject: Re: [RTG-DIR] RtgDir review: >>> draft-ietf-mif-dhcpv6-route-option-00.txt >>>> >>>> Hi Joel, Adrian, >>>> >>>> Let me be devil's advocate - since RFC 3442 provides similar function >>> for IPv4, why would we want to do more ask for an similar applicability >>> and scaling caveats? >>>> >>>> Thanks, >>>> Acee >>>> On Jan 13, 2011, at 6:54 PM, Adrian Farrel wrote: >>>> >>>>> Hi, >>>>> >>>>> Of course, the I-D is not in WG last call and has, in fact, only >>> just been >>>>> adopted by the WG, but I asked for an early Routing Directorate >>> review because >>>>> the Abstract of the I-D worried me. >>>>> >>>>> Can we (authors, WG chairs, ADs, and Routing D irectorate) have a >>> discussion >>>>> about the question Joel asks, and see whether this idea constitutes >>> "dynamic >>>>> configuration of static routes on a host" or something more scary? >>>>> >>>>> Many thanks, >>>>> Adrian >>>>> >>>>>> -----Original Message----- >>>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>>>> Sent: 13 January 2011 23:46 >>>>>> To: rtg-ads@tools.ietf.org >>>>>> Cc: rtg-dir@ietf.org; >>> draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org >>>>>> Subject: RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt >>>>>> >>>>>> Hello, >>>>>> >>>>>> I have been selected as the Routing Directorate reviewer for this >>> draft. >>>>>> The Routing Directorate seeks to review all routing or routing-related >>>>>> drafts as they pass through IETF last call and IESG review. The purpose >>>>> ;> of the review is to provide assistance to the Routing ADs. For more >>>>>> information about the Routing Directorate, please see >>>>>> http://www.ietf.org/iesg/directorate/routing.html >>>>>> >>>>>> Although these comments are primarily for the use of the Routing >>> ADs, it >>>>>> would be helpful if you could consider them along with any other IETF >>>>>> Last Call comments that you receive, and strive to resolve them through >>>>>> discussion or by updating the draft. >>>>>> >>>>>> Document: draft-ietf-mif-dhcpv6-route-option-00.txt >>>>>> Reviewer: Joel M. Halpern >>>>>> Review Date: 13-Jan-2011 >>>>>> IETF LC End Date: N/A >>>>>> Intended Status: Standards Track >>>>>> >>>>>> Summary: I have significant concerns about this document and recommend >>>>>> that the Routing ADs discuss these issues further with the authors. >>>>>> >>>>>> Comments: >>>>>> >>>>>> Major Issues: >>>>>> Given the existence of RFC 3442, I will not investigate the >>>>>> question of whether this is a sensible strategy for directing hosts. I >>>>>> do understand that there are good reasons for wanting to do this. >>>>>> However, it seems to me that there needs to be a discussion of how this >>>>>> will be made consistent with routing. A configured preference of this >>>>>> sort could easily cause a host to send messages into a long-lived >>>>>> temporary black hole, even when there is another path. Is there an >>>>>> expectation that this will somehow be synchronized with teh routing >>>>>> system? If so, how? If not, what are the consequences if things get >>>>>> de-synchronized. >>>>>> >>>>>> Minor Issues: >>>>>> I presume that the re ason there is no discussion of size issues, as >>>>>> there is in RFC 3442, is due to some difference in DHCPv6 vs DHCPv4? It >>>>>> would seem that even if this is a non-issue, this document should say >>>>>> why it is a non-issue. (It seems likely that excessive use of this >>>>>> option by an administrator could cause difficulties.) >>>>>> >>>>>> Nits: >>>>>> The introduction begins with the phrasing "The Neighbor Discovery >>>>>> (ICMPv6) protocol". While ND rides on top of ICMPv6, it is not the same >>>>>> as ICMPv6. The parenthetical is misleading rather than helpful. Please >>>>>> remove it. >>>>>> In contrast, it would be helpful if the beginning of the next >>>>>> sentence, "Extensions to the protocol defined in [RFC4191]" actually >>>>>> included the words "Router Advertisement" in the text, since that is >>>>>> what protocol is referred to without being named. >>>>>> >>>>>> It would seem a good idea to include a reference to the current >>>>>> specification of DHCPv6 the first time it is mentioned. >>>>>> >>>>>> It would be clearer (not technically different, but clearer) if the >>>>>> first and second sentence in section 4 each indicated what message >>>>>> (presumably request and response respectively) is being used to carry >>>>>> this information. Even if obvious, it would also be good if the second >>>>>> sentence referred to whatever option holder the response message uses, >>>>>> in parallel with the construction of the first sentence. >>>>>> >>>>>> The text in section 4.1 as written makes it appear that routes are >>>>>> sent individually, rather than the description of the first part of >>>>>> section 4 or the actual description of the format of the >>>>>> OPTION_NEXT_HOP. (As written in 4.1, one is led to expect pairs of >>>>>> next-hops and routes, which is clearly not what you actually intend.) >>>>>> >>>>>> Yours, >>>>>> Joel M. Halpern >>>>> >>>> > > From Adrian.Farrel@huawei.com Mon Mar 28 23:21:11 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE6013A67EF for ; Mon, 28 Mar 2011 23:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.043 X-Spam-Level: X-Spam-Status: No, score=-103.043 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599, 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 m4o80Eiyj45Y for ; Mon, 28 Mar 2011 23:20:50 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id E293A3A6ABA for ; Mon, 28 Mar 2011 23:20:41 -0700 (PDT) Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIT00H2H312HS@usaga01-in.huawei.com> for rtg-dir@ietf.org; Tue, 29 Mar 2011 01:22:14 -0500 (CDT) Received: from 950129200 (dhcp-15a5.meeting.ietf.org [130.129.21.165]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LIT00FRH310W3@usaga01-in.huawei.com> for rtg-dir@ietf.org; Tue, 29 Mar 2011 01:22:14 -0500 (CDT) Date: Tue, 29 Mar 2011 08:22:10 +0200 From: Adrian Farrel In-reply-to: <4D908639.906@gmail.com> To: 'Tomasz Mrugalski' , 'Hui Deng' Message-id: <06cb01cbedd9$a5521fe0$eff65fa0$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: AQKzeNGgyTvUlNrC6NMrNhCvH+xYUgFMGYVLAYL8XJoCEoTxMwJTcFhpkjsYkvA= References: <4D2F8EAA.7060908@joelhalpern.com> <059a01cbb37d$33bbf130$9b33d390$@huawei.com> <22B64EC5-E934-419C-ADC9-18A40E8ACFE1@ericsson.com> <4D908639.906@gmail.com> Cc: rtg-dir@ietf.org, wdec.ietf@gmail.com, draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org, acee.lindem@ericsson.com, rtg-ads@tools.ietf.org, jmh@joelhalpern.com Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 06:21:12 -0000 I'm sorry to be difficult. IETF week is a bit busy for an AD and finding a serious piece of time to chat is hard. An option is for the authors to schedule some time with Joel to discuss his review and issues, and then schedule a different time (or send an email) to summarise the conclusions to me. Cheers, Adrian > -----Original Message----- > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behalf Of > Tomasz Mrugalski > Sent: 28 March 2011 15:00 > To: Hui Deng > Cc: rtg-dir@ietf.org; wdec.ietf@gmail.com; draft-ietf-mif-dhcpv6-route- > option.all@tools.ietf.org; acee.lindem@ericsson.com; > Adrian.Farrel@huawei.com; rtg-ads@tools.ietf.org; jmh@joelhalpern.com > Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt > > On 11-03-09 22:27, Hui Deng wrote: > > Hi Adrian, all > > > > Could we meet together during the coming IETF meeting about this issue, > > please feel free to propose your available time? > Are we planning to meet? If that is so, I'm available *except* following > times: > Tuesday 900-1100 > Wednesday 900-1130, 19 or later > Thursday 1300-1500 > > Tomek > > >> From: acee.lindem@ericsson.com > >> To: Adrian.Farrel@huawei.com > >> CC: rtg-ads@tools.ietf.org; > > draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org; rtg-dir@ietf.org; > > jmh@joelhalpern.com > >> Date: Thu, 10 Feb 2011 13:27:29 -0500 > >> Subject: Re: [RTG-DIR] RtgDir review: > > draft-ietf-mif-dhcpv6-route-option-00.txt > >> > >> Hi Joel, Adrian, > >> > >> Let me be devil's advocate - since RFC 3442 provides similar function > > for IPv4, why would we want to do more ask for an similar applicability > > and scaling caveats? > >> > >> Thanks, > >> Acee > >> On Jan 13, 2011, at 6:54 PM, Adrian Farrel wrote: > >> > >> > Hi, > >> > > >> > Of course, the I-D is not in WG last call and has, in fact, only > > just been > >> > adopted by the WG, but I asked for an early Routing Directorate > > review because > >> > the Abstract of the I-D worried me. > >> > > >> > Can we (authors, WG chairs, ADs, and Routing D irectorate) have a > > discussion > >> > about the question Joel asks, and see whether this idea constitutes > > "dynamic > >> > configuration of static routes on a host" or something more scary? > >> > > >> > Many thanks, > >> > Adrian > >> > > >> >> -----Original Message----- > >> >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >> >> Sent: 13 January 2011 23:46 > >> >> To: rtg-ads@tools.ietf.org > >> >> Cc: rtg-dir@ietf.org; > > draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org > >> >> Subject: RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt > >> >> > >> >> Hello, > >> >> > >> >> I have been selected as the Routing Directorate reviewer for this > > draft. > >> >> The Routing Directorate seeks to review all routing or routing-related > >> >> drafts as they pass through IETF last call and IESG review. The purpose > >> > ;> of the review is to provide assistance to the Routing ADs. For more > >> >> information about the Routing Directorate, please see > >> >> http://www.ietf.org/iesg/directorate/routing.html > >> >> > >> >> Although these comments are primarily for the use of the Routing > > ADs, it > >> >> would be helpful if you could consider them along with any other IETF > >> >> Last Call comments that you receive, and strive to resolve them through > >> >> discussion or by updating the draft. > >> >> > >> >> Document: draft-ietf-mif-dhcpv6-route-option-00.txt > >> >> Reviewer: Joel M. Halpern > >> >> Review Date: 13-Jan-2011 > >> >> IETF LC End Date: N/A > >> >> Intended Status: Standards Track > >> >> > >> >> Summary: I have significant concerns about this document and recommend > >> >> that the Routing ADs discuss these issues further with the authors. > >> >> > >> >> Comments: > >> >> > >> >> Major Issues: > >> >> Given the existence of RFC 3442, I will not investigate the > >> >> question of whether this is a sensible strategy for directing hosts. I > >> >> do understand that there are good reasons for wanting to do this. > >> >> However, it seems to me that there needs to be a discussion of how this > >> >> will be made consistent with routing. A configured preference of this > >> >> sort could easily cause a host to send messages into a long-lived > >> >> temporary black hole, even when there is another path. Is there an > >> >> expectation that this will somehow be synchronized with teh routing > >> >> system? If so, how? If not, what are the consequences if things get > >> >> de-synchronized. > >> >> > >> >> Minor Issues: > >> >> I presume that the re ason there is no discussion of size issues, as > >> >> there is in RFC 3442, is due to some difference in DHCPv6 vs DHCPv4? It > >> >> would seem that even if this is a non-issue, this document should say > >> >> why it is a non-issue. (It seems likely that excessive use of this > >> >> option by an administrator could cause difficulties.) > >> >> > >> >> Nits: > >> >> The introduction begins with the phrasing "The Neighbor Discovery > >> >> (ICMPv6) protocol". While ND rides on top of ICMPv6, it is not the same > >> >> as ICMPv6. The parenthetical is misleading rather than helpful. Please > >> >> remove it. > >> >> In contrast, it would be helpful if the beginning of the next > >> >> sentence, "Extensions to the protocol defined in [RFC4191]" actually > >> >> included the words "Router Advertisement" in the text, since that is > >> >> what protocol is referred to without being named. > >> >> > >> >> It would seem a good idea to include a reference to the current > >> >> specification of DHCPv6 the first time it is mentioned. > >> >> > >> >> It would be clearer (not technically different, but clearer) if the > >> >> first and second sentence in section 4 each indicated what message > >> >> (presumably request and response respectively) is being used to carry > >> >> this information. Even if obvious, it would also be good if the second > >> >> sentence referred to whatever option holder the response message uses, > >> >> in parallel with the construction of the first sentence. > >> >> > >> >> The text in section 4.1 as written makes it appear that routes are > >> >> sent individually, rather than the description of the first part of > >> >> section 4 or the actual description of the format of the > >> >> OPTION_NEXT_HOP. (As written in 4.1, one is led to expect pairs of > >> >> next-hops and routes, which is clearly not what you actually intend.) > >> >> > >> >> Yours, > >> >> Joel M. Halpern > >> > > >> From denghui02@hotmail.com Tue Mar 29 04:57:50 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7387028C111 for ; Tue, 29 Mar 2011 04:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=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 AeOgM-SU0xtO for ; Tue, 29 Mar 2011 04:57:48 -0700 (PDT) Received: from col0-omc2-s5.col0.hotmail.com (col0-omc2-s5.col0.hotmail.com [65.55.34.79]) by core3.amsl.com (Postfix) with ESMTP id 88B2F3A683D for ; Tue, 29 Mar 2011 04:57:39 -0700 (PDT) Received: from COL118-W51 ([65.55.34.72]) by col0-omc2-s5.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Mar 2011 04:59:17 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_5c0b82cd-afd2-4531-abb9-8787a4ce1755_" X-Originating-IP: [130.129.22.213] From: Hui Deng To: , Date: Tue, 29 Mar 2011 19:59:17 +0800 Importance: Normal In-Reply-To: <4D90C124.9020102@joelhalpern.com> References: <4D2F8EAA.7060908@joelhalpern.com> <059a01cbb37d$33bbf130$9b33d390$@huawei.com> <22B64EC5-E934-419C-ADC9-18A40E8ACFE1@ericsson.com> <4D908639.906@gmail.com> <052c01cbed63$4434fe60$cc9efb20$@huawei.com>, <4D90C124.9020102@joelhalpern.com> MIME-Version: 1.0 X-OriginalArrivalTime: 29 Mar 2011 11:59:17.0971 (UTC) FILETIME=[BB4CC230:01CBEE08] X-Mailman-Approved-At: Tue, 29 Mar 2011 07:13:02 -0700 Cc: rtg-dir@ietf.org, wdec.ietf@gmail.com, tomasz.mrugalski@gmail.com, draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org, acee.lindem@ericsson.com, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 11:57:50 -0000 --_5c0b82cd-afd2-4531-abb9-8787a4ce1755_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Wednesday morning means 8am-9am? Woj and Tomasz, does this time work for you two? thanks -Hui > Date: Mon, 28 Mar 2011 13:11:00 -0400 > From: jmh@joelhalpern.com > To: Adrian.Farrel@huawei.com > CC: tomasz.mrugalski@gmail.com; denghui02@hotmail.com; rtg-dir@ietf.org; wdec.ietf@gmail.com; draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org; acee.lindem@ericsson.com; rtg-ads@tools.ietf.org > Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt > > I could squeeze out Wednesday morning. Friday morning is definitely > KARP. Friday after 3 is best. > > Yours, > Joel > > On 3/28/2011 12:14 PM, Adrian Farrel wrote: > > Hi, > > > > Yes, we should try to discuss this face-to-face. > > > > I would love to do this with Joel. > > Are you all around on Friday (I'm guessing Joel will be in Karp :-) > > > > Friday lunch or after 3pm works really well for me. > > > > Adrian > > > >> -----Original Message----- > >> From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behalf Of > >> Tomasz Mrugalski > >> Sent: 28 March 2011 15:00 > >> To: Hui Deng > >> Cc: rtg-dir@ietf.org; wdec.ietf@gmail.com; draft-ietf-mif-dhcpv6-route- > >> option.all@tools.ietf.org; acee.lindem@ericsson.com; > >> Adrian.Farrel@huawei.com; rtg-ads@tools.ietf.org; jmh@joelhalpern.com > >> Subject: Re: [RTG-DIR] RtgDir review: > > draft-ietf-mif-dhcpv6-route-option-00.txt > >> > >> On 11-03-09 22:27, Hui Deng wrote: > >>> Hi Adrian, all > >>> > >>> Could we meet together during the coming IETF meeting about this issue, > >>> please feel free to propose your available time? > >> Are we planning to meet? If that is so, I'm available *except* following > >> times: > >> Tuesday 900-1100 > >> Wednesday 900-1130, 19 or later > >> Thursday 1300-1500 > >> > >> Tomek > >> > >>>> From: acee.lindem@ericsson.com > >>>> To: Adrian.Farrel@huawei.com > >>>> CC: rtg-ads@tools.ietf.org; > >>> draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org; rtg-dir@ietf.org; > >>> jmh@joelhalpern.com > >>>> Date: Thu, 10 Feb 2011 13:27:29 -0500 > >>>> Subject: Re: [RTG-DIR] RtgDir review: > >>> draft-ietf-mif-dhcpv6-route-option-00.txt > >>>> > >>>> Hi Joel, Adrian, > >>>> > >>>> Let me be devil's advocate - since RFC 3442 provides similar function > >>> for IPv4, why would we want to do more ask for an similar applicability > >>> and scaling caveats? > >>>> > >>>> Thanks, > >>>> Acee > >>>> On Jan 13, 2011, at 6:54 PM, Adrian Farrel wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> Of course, the I-D is not in WG last call and has, in fact, only > >>> just been > >>>>> adopted by the WG, but I asked for an early Routing Directorate > >>> review because > >>>>> the Abstract of the I-D worried me. > >>>>> > >>>>> Can we (authors, WG chairs, ADs, and Routing D irectorate) have a > >>> discussion > >>>>> about the question Joel asks, and see whether this idea constitutes > >>> "dynamic > >>>>> configuration of static routes on a host" or something more scary? > >>>>> > >>>>> Many thanks, > >>>>> Adrian > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >>>>>> Sent: 13 January 2011 23:46 > >>>>>> To: rtg-ads@tools.ietf.org > >>>>>> Cc: rtg-dir@ietf.org; > >>> draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org > >>>>>> Subject: RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt > >>>>>> > >>>>>> Hello, > >>>>>> > >>>>>> I have been selected as the Routing Directorate reviewer for this > >>> draft. > >>>>>> The Routing Directorate seeks to review all routing or routing-related > >>>>>> drafts as they pass through IETF last call and IESG review. The purpose > >>>>> ;> of the review is to provide assistance to the Routing ADs. For more > >>>>>> information about the Routing Directorate, please see > >>>>>> http://www.ietf.org/iesg/directorate/routing.html > >>>>>> > >>>>>> Although these comments are primarily for the use of the Routing > >>> ADs, it > >>>>>> would be helpful if you could consider them along with any other IETF > >>>>>> Last Call comments that you receive, and strive to resolve them through > >>>>>> discussion or by updating the draft. > >>>>>> > >>>>>> Document: draft-ietf-mif-dhcpv6-route-option-00.txt > >>>>>> Reviewer: Joel M. Halpern > >>>>>> Review Date: 13-Jan-2011 > >>>>>> IETF LC End Date: N/A > >>>>>> Intended Status: Standards Track > >>>>>> > >>>>>> Summary: I have significant concerns about this document and recommend > >>>>>> that the Routing ADs discuss these issues further with the authors. > >>>>>> > >>>>>> Comments: > >>>>>> > >>>>>> Major Issues: > >>>>>> Given the existence of RFC 3442, I will not investigate the > >>>>>> question of whether this is a sensible strategy for directing hosts. I > >>>>>> do understand that there are good reasons for wanting to do this. > >>>>>> However, it seems to me that there needs to be a discussion of how this > >>>>>> will be made consistent with routing. A configured preference of this > >>>>>> sort could easily cause a host to send messages into a long-lived > >>>>>> temporary black hole, even when there is another path. Is there an > >>>>>> expectation that this will somehow be synchronized with teh routing > >>>>>> system? If so, how? If not, what are the consequences if things get > >>>>>> de-synchronized. > >>>>>> > >>>>>> Minor Issues: > >>>>>> I presume that the re ason there is no discussion of size issues, as > >>>>>> there is in RFC 3442, is due to some difference in DHCPv6 vs DHCPv4? It > >>>>>> would seem that even if this is a non-issue, this document should say > >>>>>> why it is a non-issue. (It seems likely that excessive use of this > >>>>>> option by an administrator could cause difficulties.) > >>>>>> > >>>>>> Nits: > >>>>>> The introduction begins with the phrasing "The Neighbor Discovery > >>>>>> (ICMPv6) protocol". While ND rides on top of ICMPv6, it is not the same > >>>>>> as ICMPv6. The parenthetical is misleading rather than helpful. Please > >>>>>> remove it. > >>>>>> In contrast, it would be helpful if the beginning of the next > >>>>>> sentence, "Extensions to the protocol defined in [RFC4191]" actually > >>>>>> included the words "Router Advertisement" in the text, since that is > >>>>>> what protocol is referred to without being named. > >>>>>> > >>>>>> It would seem a good idea to include a reference to the current > >>>>>> specification of DHCPv6 the first time it is mentioned. > >>>>>> > >>>>>> It would be clearer (not technically different, but clearer) if the > >>>>>> first and second sentence in section 4 each indicated what message > >>>>>> (presumably request and response respectively) is being used to carry > >>>>>> this information. Even if obvious, it would also be good if the second > >>>>>> sentence referred to whatever option holder the response message uses, > >>>>>> in parallel with the construction of the first sentence. > >>>>>> > >>>>>> The text in section 4.1 as written makes it appear that routes are > >>>>>> sent individually, rather than the description of the first part of > >>>>>> section 4 or the actual description of the format of the > >>>>>> OPTION_NEXT_HOP. (As written in 4.1, one is led to expect pairs of > >>>>>> next-hops and routes, which is clearly not what you actually intend.) > >>>>>> > >>>>>> Yours, > >>>>>> Joel M. Halpern > >>>>> > >>>> > > > > --_5c0b82cd-afd2-4531-abb9-8787a4ce1755_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Wednesday morning means 8am-9am?
 
Woj and Tomasz, does this time work for you two?
 
thanks
 
-Hui
 
> Date: Mon, 28 Mar 2011 13:11:00 -0400
> From: jmh@joelhalpern.com
> To: Adrian.Farrel@huawei.com
> CC: tomasz.mrugalski@gmail.com; denghui02@hotmail.com; rtg-dir@ietf.org; wdec.ietf@gmail.com; draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org; acee.lindem@ericsson.com; rtg-ads@tools.ietf.org
> Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt
>
> I could squeeze out Wednesday morning. Friday morning is definitely
> KARP. Friday after 3 is best.
>
> Yours,
> Joel
>
> On 3/28/2011 12:14 PM, Adrian Farrel wrote:
> > Hi,
> >
> > Yes, we should try to discuss this face-to-face.
> >
> > I would love to do this with Joel.
> > Are you all around on Friday (I'm guessing Joel will be in Karp :-)
> >
> > Friday lunch or after 3pm works really well for me.
> >
> > Adrian
> >
> >> -----Original Message-----
> >> From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behalf Of
> >> Tomasz Mrugalski
> >> Sent: 28 March 2011 15:00
> >> To: Hui Deng
> >> Cc: rtg-dir@ietf.org; wdec.ietf@gmail.com; draft-ietf-mif-dhcpv6-route-
> >> option.all@tools.ietf.org; acee.lindem@ericsson.com;
> >> Adrian.Farrel@huawei.com; rtg-ads@tools.ietf.org; jmh@joelhalpern.com
> >> Subject: Re: [RTG-DIR] RtgDir review:
> > draft-ietf-mif-dhcpv6-route-option-00.txt
> >>
> >> On 11-03-09 22:27, Hui Deng wrote:
> >>> Hi Adrian, all
> >>>
> >>> Could we meet together during the coming IETF meeting about this issue,
> >>> please feel free to propose your available time?
> >> Are we planning to meet? If that is so, I'm available *except* following
> &g t;> times:
> >> Tuesday 900-1100
> >> Wednesday 900-1130, 19 or later
> >> Thursday 1300-1500
> >>
> >> Tomek
> >>
> >>>> From: acee.lindem@ericsson.com
> >>>> To: Adrian.Farrel@huawei.com
> >>>> CC: rtg-ads@tools.ietf.org;
> >>> draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org; rtg-dir@ietf.org;
> >>> jmh@joelhalpern.com
> >>>> Date: Thu, 10 Feb 2011 13:27:29 -0500
> >>>> Subject: Re: [RTG-DIR] RtgDir review:
> >>> draft-ietf-mif-dhcpv6-route-option-00.txt
> >>>>
> >>>> Hi Joel, Adrian,
> >>>>
> >>>> Let me be devil's advocate - since RFC 3442 provides similar function
> >>> for IPv4, why would we want to do more ask for an similar applicability
> >>> and scaling caveats?
> >>>>
> >>>> Thanks,
> >>>> Acee
> >>>> On Jan 13, 2011, at 6:54 PM, Adrian Farrel wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> Of course, the I-D is not in WG last call and has, in fact, only
> >>> just been
> >>>>> adopted by the WG, but I asked for an early Routing Directorate
> >>> review because
> >>>>> the Abstract of the I-D worried me.
> >>>>>
> >>>>> Can we (authors, WG chairs, ADs, and Routing D irectorate) have a
> >>> discussion
> >>>>> about the question Joel asks, and see whether this idea constitutes
> >>> "dynamic
> >>>>> configuration of static routes on a host" or something more scary?
> >>>>>
> >>>>> Many thanks,
> >>>>> Adrian
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> >>>>>> Sent: 13 January 2011 23:46
> >>>>>> To: rtg-ads@tools.ietf.org
> >>>>>> Cc: rtg-dir@ietf.org;
> >>> draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org
> >>>>>> Subject: RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt
> >>>>>>
> >>>>>> Hello,
> >>>>>>
> >>>>>> I have been selected as the Routing Directorate reviewer for this
> >>> draft.
> >>>>>> The Routing Directorate seeks to review all routing or routing-related
> >>>>>> drafts as they pass through IETF last call and IESG review. The purpose
> >>>>> ;> of the review is to provide assistance to the Routing ADs. For more
> >>>>>> information about the Routing Directorate, please see
> >>>>>> http://www.ietf.org/iesg/directorate/routing.html
> >>>>>>
> >>>>>> Although these comments are primarily for the use of the Routing
> >>> ADs, it
> >>>>>> would be helpful if you could consider them along with any other IETF
> >>>>>> Last Call comments that you receive, and strive to resolve them through
> >>>>>> discussion or by updating the draft.
> >>>>>>
> >>>>>> Document: draft-ietf-mif-dhcpv6-route-option-00.txt
> >>>>>> Reviewer: Joel M. Halpern
> >>>>>> Review Date: 13- Jan-2011
> >>>>>> IETF LC End Date: N/A
> >>>>>> Intended Status: Standards Track
> >>>>>>
> >>>>>> Summary: I have significant concerns about this document and recommend
> >>>>>> that the Routing ADs discuss these issues further with the authors.
> >>>>>>
> >>>>>> Comments:
> >>>>>>
> >>>>>> Major Issues:
> >>>>>> Given the existence of RFC 3442, I will not investigate the
> >>>>>> question of whether this is a sensible strategy for directing hosts. I
> >>>>>> do understand that there are good reasons for wanting to do this.
> >>>>>> However, it seems to me that there needs to be a discussion of how this
> >>>>>> will be made consistent with ro uting. A configured preference of this
> >>>>>> sort could easily cause a host to send messages into a long-lived
> >>>>>> temporary black hole, even when there is another path. Is there an
> >>>>>> expectation that this will somehow be synchronized with teh routing
> >>>>>> system? If so, how? If not, what are the consequences if things get
> >>>>>> de-synchronized.
> >>>>>>
> >>>>>> Minor Issues:
> >>>>>> I presume that the re ason there is no discussion of size issues, as
> >>>>>> there is in RFC 3442, is due to some difference in DHCPv6 vs DHCPv4? It
> >>>>>> would seem that even if this is a non-issue, this document should say
> >>>>>> why it is a non-issue. (It seems likely that excessive use of this
> & gt;>>>>> option by an administrator could cause difficulties.)
> >>>>>>
> >>>>>> Nits:
> >>>>>> The introduction begins with the phrasing "The Neighbor Discovery
> >>>>>> (ICMPv6) protocol". While ND rides on top of ICMPv6, it is not the same
> >>>>>> as ICMPv6. The parenthetical is misleading rather than helpful. Please
> >>>>>> remove it.
> >>>>>> In contrast, it would be helpful if the beginning of the next
> >>>>>> sentence, "Extensions to the protocol defined in [RFC4191]" actually
> >>>>>> included the words "Router Advertisement" in the text, since that is
> >>>>>> what protocol is referred to without being named.
> >>>>>>
> >>>>>> It would seem a good idea to include a reference to the current
> >>>>>> specification of DHCPv6 the first time it is mentioned.
> >>>>>>
> >>>>>> It would be clearer (not technically different, but clearer) if the
> >>>>>> first and second sentence in section 4 each indicated what message
> >>>>>> (presumably request and response respectively) is being used to carry
> >>>>>> this information. Even if obvious, it would also be good if the second
> >>>>>> sentence referred to whatever option holder the response message uses,
> >>>>>> in parallel with the construction of the first sentence.
> >>>>>>
> >>>>>> The text in section 4.1 as written makes it appear that routes are
> >>>>>> sent individually, rather than the description of the first part of
> ; >>>>>> section 4 or the actual description of the format of the
> >>>>>> OPTION_NEXT_HOP. (As written in 4.1, one is led to expect pairs of
> >>>>>> next-hops and routes, which is clearly not what you actually intend.)
> >>>>>>
> >>>>>> Yours,
> >>>>>> Joel M. Halpern
> >>>>>
> >>>>
> >
> >
--_5c0b82cd-afd2-4531-abb9-8787a4ce1755_-- From wdec@cisco.com Mon Mar 28 10:27:40 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D3C228C11C for ; Mon, 28 Mar 2011 10:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 KcOIB70QfOUG for ; Mon, 28 Mar 2011 10:27:38 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id E683428C119 for ; Mon, 28 Mar 2011 10:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=7062; q=dns/txt; s=iport; t=1301333356; x=1302542956; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=3TwEpAVe9ZJ0xsLJuc3sk46jfXPHl8VnFqa732uzCHQ=; b=NoXqXCMgpAJd8dGaOTx+IIgbC6QxhGi0aqDxlmE62KLfdeN/VLU4HE4/ 9IuXsKzDnOvaO6M5KU7ZHALPIHAVU0oEDJmwN6cKWOA03yuEv10w9awWt 1kBR0GMk8+YJD2UVzQqlmtHUSEql9w9Wol0k8AKzQpweZh8CfuG1biljI Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgEAJTEkE2Q/khMgWdsb2JhbAClRhUBFiYliGueQpwOhWkEjHeDWoMl X-IronPort-AV: E=Sophos;i="4.63,256,1299456000"; d="scan'208";a="23496237" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 28 Mar 2011 17:29:15 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2SHTEkC002294; Mon, 28 Mar 2011 17:29:14 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Mar 2011 19:29:14 +0200 Received: from 10.55.85.31 ([10.55.85.31]) by XMB-AMS-111.cisco.com ([144.254.74.86]) with Microsoft Exchange Server HTTP-DAV ; Mon, 28 Mar 2011 17:29:14 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Mon, 28 Mar 2011 19:29:11 +0100 From: Wojciech Dec To: "Joel M. Halpern" , Message-ID: Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt Thread-Index: AcvtbaZzB15qAjZjtkO1NGLw2VFeUg== In-Reply-To: <4D90C124.9020102@joelhalpern.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 28 Mar 2011 17:29:14.0889 (UTC) FILETIME=[A8C4F790:01CBED6D] X-Mailman-Approved-At: Tue, 29 Mar 2011 07:13:13 -0700 Cc: rtg-dir@ietf.org, wdec.ietf@gmail.com, 'Tomasz Mrugalski' , draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org, acee.lindem@ericsson.com, rtg-ads@tools.ietf.org, 'Hui Deng' Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 17:27:40 -0000 Afraid that Friday won't work for me (leaving Thu evening)... -Woj. On 28/03/2011 18:11, "Joel M. Halpern" wrote: > I could squeeze out Wednesday morning. Friday morning is definitely > KARP. Friday after 3 is best. > > Yours, > Joel > > On 3/28/2011 12:14 PM, Adrian Farrel wrote: >> Hi, >> >> Yes, we should try to discuss this face-to-face. >> >> I would love to do this with Joel. >> Are you all around on Friday (I'm guessing Joel will be in Karp :-) >> >> Friday lunch or after 3pm works really well for me. >> >> Adrian >> >>> -----Original Message----- >>> From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behalf >>> Of >>> Tomasz Mrugalski >>> Sent: 28 March 2011 15:00 >>> To: Hui Deng >>> Cc: rtg-dir@ietf.org; wdec.ietf@gmail.com; draft-ietf-mif-dhcpv6-route- >>> option.all@tools.ietf.org; acee.lindem@ericsson.com; >>> Adrian.Farrel@huawei.com; rtg-ads@tools.ietf.org; jmh@joelhalpern.com >>> Subject: Re: [RTG-DIR] RtgDir review: >> draft-ietf-mif-dhcpv6-route-option-00.txt >>> >>> On 11-03-09 22:27, Hui Deng wrote: >>>> Hi Adrian, all >>>> >>>> Could we meet together during the coming IETF meeting about this issue, >>>> please feel free to propose your available time? >>> Are we planning to meet? If that is so, I'm available *except* following >>> times: >>> Tuesday 900-1100 >>> Wednesday 900-1130, 19 or later >>> Thursday 1300-1500 >>> >>> Tomek >>> >>>>> From: acee.lindem@ericsson.com >>>>> To: Adrian.Farrel@huawei.com >>>>> CC: rtg-ads@tools.ietf.org; >>>> draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org; rtg-dir@ietf.org; >>>> jmh@joelhalpern.com >>>>> Date: Thu, 10 Feb 2011 13:27:29 -0500 >>>>> Subject: Re: [RTG-DIR] RtgDir review: >>>> draft-ietf-mif-dhcpv6-route-option-00.txt >>>>> >>>>> Hi Joel, Adrian, >>>>> >>>>> Let me be devil's advocate - since RFC 3442 provides similar function >>>> for IPv4, why would we want to do more ask for an similar applicability >>>> and scaling caveats? >>>>> >>>>> Thanks, >>>>> Acee >>>>> On Jan 13, 2011, at 6:54 PM, Adrian Farrel wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Of course, the I-D is not in WG last call and has, in fact, only >>>> just been >>>>>> adopted by the WG, but I asked for an early Routing Directorate >>>> review because >>>>>> the Abstract of the I-D worried me. >>>>>> >>>>>> Can we (authors, WG chairs, ADs, and Routing D irectorate) have a >>>> discussion >>>>>> about the question Joel asks, and see whether this idea constitutes >>>> "dynamic >>>>>> configuration of static routes on a host" or something more scary? >>>>>> >>>>>> Many thanks, >>>>>> Adrian >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>>>>> Sent: 13 January 2011 23:46 >>>>>>> To: rtg-ads@tools.ietf.org >>>>>>> Cc: rtg-dir@ietf.org; >>>> draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org >>>>>>> Subject: RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I have been selected as the Routing Directorate reviewer for this >>>> draft. >>>>>>> The Routing Directorate seeks to review all routing or routing-related >>>>>>> drafts as they pass through IETF last call and IESG review. The purpose >>>>>> ;> of the review is to provide assistance to the Routing ADs. For more >>>>>>> information about the Routing Directorate, please see >>>>>>> http://www.ietf.org/iesg/directorate/routing.html >>>>>>> >>>>>>> Although these comments are primarily for the use of the Routing >>>> ADs, it >>>>>>> would be helpful if you could consider them along with any other IETF >>>>>>> Last Call comments that you receive, and strive to resolve them through >>>>>>> discussion or by updating the draft. >>>>>>> >>>>>>> Document: draft-ietf-mif-dhcpv6-route-option-00.txt >>>>>>> Reviewer: Joel M. Halpern >>>>>>> Review Date: 13-Jan-2011 >>>>>>> IETF LC End Date: N/A >>>>>>> Intended Status: Standards Track >>>>>>> >>>>>>> Summary: I have significant concerns about this document and recommend >>>>>>> that the Routing ADs discuss these issues further with the authors. >>>>>>> >>>>>>> Comments: >>>>>>> >>>>>>> Major Issues: >>>>>>> Given the existence of RFC 3442, I will not investigate the >>>>>>> question of whether this is a sensible strategy for directing hosts. I >>>>>>> do understand that there are good reasons for wanting to do this. >>>>>>> However, it seems to me that there needs to be a discussion of how this >>>>>>> will be made consistent with routing. A configured preference of this >>>>>>> sort could easily cause a host to send messages into a long-lived >>>>>>> temporary black hole, even when there is another path. Is there an >>>>>>> expectation that this will somehow be synchronized with teh routing >>>>>>> system? If so, how? If not, what are the consequences if things get >>>>>>> de-synchronized. >>>>>>> >>>>>>> Minor Issues: >>>>>>> I presume that the re ason there is no discussion of size issues, as >>>>>>> there is in RFC 3442, is due to some difference in DHCPv6 vs DHCPv4? It >>>>>>> would seem that even if this is a non-issue, this document should say >>>>>>> why it is a non-issue. (It seems likely that excessive use of this >>>>>>> option by an administrator could cause difficulties.) >>>>>>> >>>>>>> Nits: >>>>>>> The introduction begins with the phrasing "The Neighbor Discovery >>>>>>> (ICMPv6) protocol". While ND rides on top of ICMPv6, it is not the same >>>>>>> as ICMPv6. The parenthetical is misleading rather than helpful. Please >>>>>>> remove it. >>>>>>> In contrast, it would be helpful if the beginning of the next >>>>>>> sentence, "Extensions to the protocol defined in [RFC4191]" actually >>>>>>> included the words "Router Advertisement" in the text, since that is >>>>>>> what protocol is referred to without being named. >>>>>>> >>>>>>> It would seem a good idea to include a reference to the current >>>>>>> specification of DHCPv6 the first time it is mentioned. >>>>>>> >>>>>>> It would be clearer (not technically different, but clearer) if the >>>>>>> first and second sentence in section 4 each indicated what message >>>>>>> (presumably request and response respectively) is being used to carry >>>>>>> this information. Even if obvious, it would also be good if the second >>>>>>> sentence referred to whatever option holder the response message uses, >>>>>>> in parallel with the construction of the first sentence. >>>>>>> >>>>>>> The text in section 4.1 as written makes it appear that routes are >>>>>>> sent individually, rather than the description of the first part of >>>>>>> section 4 or the actual description of the format of the >>>>>>> OPTION_NEXT_HOP. (As written in 4.1, one is led to expect pairs of >>>>>>> next-hops and routes, which is clearly not what you actually intend.) >>>>>>> >>>>>>> Yours, >>>>>>> Joel M. Halpern >>>>>> >>>>> >> >> From loa@pi.nu Wed Mar 30 07:58:40 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5BCA3A6983 for ; Wed, 30 Mar 2011 07:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.379 X-Spam-Level: X-Spam-Status: No, score=-102.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, 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 kdYZTsVCeMbE for ; Wed, 30 Mar 2011 07:58:40 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 043823A6847 for ; Wed, 30 Mar 2011 07:58:39 -0700 (PDT) Received: from [130.129.66.247] (dhcp-42f7.meeting.ietf.org [130.129.66.247]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 2A4652A8001 for ; Wed, 30 Mar 2011 17:00:16 +0200 (CEST) Message-ID: <4D93457F.4080500@pi.nu> Date: Wed, 30 Mar 2011 17:00:15 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: rtg-dir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [RTG-DIR] bfd working group last call on draft-ietf-mpls-tp-cc-cv-rdi-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 14:58:41 -0000 BFD working group, This is to start a 19 days BFD working group last on an mpls wg draft; http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi-03.txt the draft was recently wg last called in the mpls wg, but the wg chairs of both groups has agreed that this draft should also be last called in the bfd working group. The document is part of the ongoing mpls-tp project. Please send your comments to the mpls@ietf.org mailing list. If your are not subscribed to the mpls wg list, please send to the bfd wg mailing list (rtg-bfd@ietf.org) This working group last call ends April 11. Loa George Ross Jeff and Dave mpls and bfd working group chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From loa@pi.nu Wed Mar 30 08:04:39 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A94353A6847; Wed, 30 Mar 2011 08:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.423 X-Spam-Level: X-Spam-Status: No, score=-102.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, 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 Lz-Jc3Ne+Bmu; Wed, 30 Mar 2011 08:04:38 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id A77873A6821; Wed, 30 Mar 2011 08:04:35 -0700 (PDT) Received: from [130.129.66.247] (dhcp-42f7.meeting.ietf.org [130.129.66.247]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 709782A8001; Wed, 30 Mar 2011 17:06:13 +0200 (CEST) Message-ID: <4D9346E4.2080606@pi.nu> Date: Wed, 30 Mar 2011 17:06:12 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: rtg-dir@ietf.org, Rtg-bfd@ietf.org References: <4D93457F.4080500@pi.nu> In-Reply-To: <4D93457F.4080500@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [RTG-DIR] bfd working group last call on draft-ietf-mpls-tp-cc-cv-rdi-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 15:04:39 -0000 All, someone = possibly me - mixed the mail addresses up. This was intended for the bfd working group! Though comments from the routing directorate would be welcome! /Loa On 2011-03-30 17:00, Loa Andersson wrote: > BFD working group, > > This is to start a 19 days BFD working group last on an mpls wg draft; > > http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi-03.txt > > the draft was recently wg last called in the mpls wg, but the wg chairs > of both groups has agreed that this draft should also be last called in > the bfd working group. > > The document is part of the ongoing mpls-tp project. > > Please send your comments to the mpls@ietf.org mailing list. > > If your are not subscribed to the mpls wg list, please send to the > bfd wg mailing list (rtg-bfd@ietf.org) > > This working group last call ends April 11. > > > Loa George Ross Jeff and Dave > > mpls and bfd working group chairs > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From tomasz.mrugalski@gmail.com Tue Mar 29 08:11:48 2011 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D3B23A6940 for ; Tue, 29 Mar 2011 08:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 o3NOOma0-4+V for ; Tue, 29 Mar 2011 08:11:46 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 48D9C3A6931 for ; Tue, 29 Mar 2011 08:11:46 -0700 (PDT) Received: by fxm15 with SMTP id 15so325450fxm.31 for ; Tue, 29 Mar 2011 08:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ngsIoC6QINOfyLsn98hnRcT399NdcC9Xlr/2xPVFkMI=; b=UlHV2kfIrtcn80O3ApowdSitk1F8HuxSwqzWX1RNRuFEra2JG2e5uIxhQBeaIy0mB0 LUyj+Xp9T3nX0ziCuqD5caazgPIYsmm/S7LTpxsIKIpZjTmOrg1jd77s1hMMLf9O2XXp 6IremdBtU2LMQEVwHcktIm0NRhxddLS0vjnJA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=WMXVvpbph5/DB2uHx6RFRPCniTSp+s9uCFu1rSUtRfAGPXiSBLwQOAeQoYAgnCGhEx LZs2UyMfveE7TN6kXPOS2WHyDNWiSvSwxYrwe6ZTgqCbmHAHewzr1yPGmfaAst+TcJ6y aXCu1H3O3EVHzBLX1O2nDGeNwCepPwGqi0wXE= Received: by 10.223.14.137 with SMTP id g9mr6008894faa.2.1301411566864; Tue, 29 Mar 2011 08:12:46 -0700 (PDT) Received: from MacBook-Tomasz-Mrugalski.local ([77.78.82.82]) by mx.google.com with ESMTPS id n15sm2024939fam.36.2011.03.29.08.12.44 (version=SSLv3 cipher=OTHER); Tue, 29 Mar 2011 08:12:45 -0700 (PDT) Message-ID: <4D91F6EB.1030203@gmail.com> Date: Tue, 29 Mar 2011 17:12:43 +0200 From: Tomasz Mrugalski User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Hui Deng References: <4D2F8EAA.7060908@joelhalpern.com> <059a01cbb37d$33bbf130$9b33d390$@huawei.com> <22B64EC5-E934-419C-ADC9-18A40E8ACFE1@ericsson.com> <4D908639.906@gmail.com> <052c01cbed63$4434fe60$cc9efb20$@huawei.com>, <4D90C124.9020102@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 30 Mar 2011 08:52:32 -0700 Cc: rtg-dir@ietf.org, wdec.ietf@gmail.com, draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org, acee.lindem@ericsson.com, adrian.farrel@huawei.com, rtg-ads@tools.ietf.org, jmh@joelhalpern.com Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 15:11:48 -0000 On 11-03-29 13:59, Hui Deng wrote: > Wednesday morning means 8am-9am? > > Woj and Tomasz, does this time work for you two? Wednesday 8am-9am is ok, but we need to finish on time (softwires WG starts at 9am and I'm one of the first presenters). Thursday morning is also ok for me, but definetely we want to conclude before 1pm (DHC WG meeting). Tomek > > thanks > > -Hui > >> Date: Mon, 28 Mar 2011 13:11:00 -0400 >> From: jmh@joelhalpern.com >> To: Adrian.Farrel@huawei.com >> CC: tomasz.mrugalski@gmail.com; denghui02@hotmail.com; > rtg-dir@ietf.org; wdec.ietf@gmail.com; > draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org; > acee.lindem@ericsson.com; rtg-ads@tools.ietf.org >> Subject: Re: [RTG-DIR] RtgDir review: > draft-ietf-mif-dhcpv6-route-option-00.txt >> >> I could squeeze out Wednesday morning. Friday morning is definitely >> KARP. Friday after 3 is best. >> >> Yours, >> Joel >> >> On 3/28/2011 12:14 PM, Adrian Farrel wrote: >> > Hi, >> > >> > Yes, we should try to discuss this face-to-face. >> > >> > I would love to do this with Joel. >> > Are you all around on Friday (I'm guessing Joel will be in Karp :-) >> > >> > Friday lunch or after 3pm works really well for me. >> > >> > Adrian >> > >> >> -----Original Message----- >> >> From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On > Behalf Of >> >> Tomasz Mrugalski >> >> Sent: 28 March 2011 15:00 >> >> To: Hui Deng >> >> Cc: rtg-dir@ietf.org; wdec.ietf@gmail.com; draft-ietf-mif-dhcpv6-route- >> >> option.all@tools.ietf.org; acee.lindem@ericsson.com; >> >> Adrian.Farrel@huawei.com; rtg-ads@tools.ietf.org; jmh@joelhalpern.com >> >> Subject: Re: [RTG-DIR] RtgDir review: >> > draft-ietf-mif-dhcpv6-route-option-00.txt >> >> >> >> On 11-03-09 22:27, Hui Deng wrote: >> >>> Hi Adrian, all >> >>> >> >>> Could we meet together during the coming IETF meeting about this > issue, >> >>> please feel free to propose your available time? >> >> Are we planning to meet? If that is so, I'm available *except* > following >> >> times: >> >> Tuesday 900-1100 >> >> Wednesday 900-1130, 19 or later >> >> Thursday 1300-1500 >> >> >> >> Tomek >> >> >> >>>> From: acee.lindem@ericsson.com >> >>>> To: Adrian.Farrel@huawei.com >> >>>> CC: rtg-ads@tools.ietf.org; >> >>> draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org; > rtg-dir@ietf.org; >> >>> jmh@joelhalpern.com >> >>>> Date: Thu, 10 Feb 2011 13:27:29 -0500 >> >>>> Subject: Re: [RTG-DIR] RtgDir review: >> >>> draft-ietf-mif-dhcpv6-route-option-00.txt >> >>>> >> >>>> Hi Joel, Adrian, >> >>>> >> >>>> Let me be devil's advocate - since RFC 3442 provides similar function >> >>> for IPv4, why would we want to do more ask for an similar > applicability >> >>> and scaling caveats? >> >>>> >> >>>> Thanks, >> >>>> Acee >> >>>> On Jan 13, 2011, at 6:54 PM, Adrian Farrel wrote: >> >>>> >> >>>>> Hi, >> >>>>> >> >>>>> Of course, the I-D is not in WG last call and has, in fact, only >> >>> just been >> >>>>> adopted by the WG, but I asked for an early Routing Directorate >> >>> review because >> >>>>> the Abstract of the I-D worried me. >> >>>>> >> >>>>> Can we (authors, WG chairs, ADs, and Routing D irectorate) have a >> >>> discussion >> >>>>> about the question Joel asks, and see whether this idea constitutes >> >>> "dynamic >> >>>>> configuration of static routes on a host" or something more scary? >> >>>>> >> >>>>> Many thanks, >> >>>>> Adrian >> >>>>> >> >>>>>> -----Original Message----- >> >>>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> >>>>>> Sent: 13 January 2011 23:46 >> >>>>>> To: rtg-ads@tools.ietf.org >> >>>>>> Cc: rtg-dir@ietf.org; >> >>> draft-ietf-mif-dhcpv6-route-option.all@tools.ietf.org >> >>>>>> Subject: RtgDir review: draft-ietf-mif-dhcpv6-route-option-00.txt >> >>>>>> >> >>>>>> Hello, >> >>>>>> >> >>>>>> I have been selected as the Routing Directorate reviewer for this >> >>> draft. >> >>>>>> The Routing Directorate seeks to review all routing or > routing-related >> >>>>>> drafts as they pass through IETF last call and IESG review. The > purpose >> >>>>> ;> of the review is to provide assistance to the Routing ADs. > For more >> >>>>>> information about the Routing Directorate, please see >> >>>>>> http://www.ietf.org/iesg/directorate/routing.html >> >>>>>> >> >>>>>> Although these comments are primarily for the use of the Routing >> >>> ADs, it >> >>>>>> would be helpful if you could consider them along with any > other IETF >> >>>>>> Last Call comments that you receive, and strive to resolve them > through >> >>>>>> discussion or by updating the draft. >> >>>>>> >> >>>>>> Document: draft-ietf-mif-dhcpv6-route-option-00.txt >> >>>>>> Reviewer: Joel M. Halpern >> >>>>>> Review Date: 13-Jan-2011 >> >>>>>> IETF LC End Date: N/A >> >>>>>> Intended Status: Standards Track >> >>>>>> >> >>>>>> Summary: I have significant concerns about this document and > recommend >> >>>>>> that the Routing ADs discuss these issues further with the authors. >> >>>>>> >> >>>>>> Comments: >> >>>>>> >> >>>>>> Major Issues: >> >>>>>> Given the existence of RFC 3442, I will not investigate the >> >>>>>> question of whether this is a sensible strategy for directing > hosts. I >> >>>>>> do understand that there are good reasons for wanting to do this. >> >>>>>> However, it seems to me that there needs to be a discussion of > how this >> >>>>>> will be made consistent with routing. A configured preference > of this >> >>>>>> sort could easily cause a host to send messages into a long-lived >> >>>>>> temporary black hole, even when there is another path. Is there an >> >>>>>> expectation that this will somehow be synchronized with teh routing >> >>>>>> system? If so, how? If not, what are the consequences if things get >> >>>>>> de-synchronized. >> >>>>>> >> >>>>>> Minor Issues: >> >>>>>> I presume that the re ason there is no discussion of size > issues, as >> >>>>>> there is in RFC 3442, is due to some difference in DHCPv6 vs > DHCPv4? It >> >>>>>> would seem that even if this is a non-issue, this document > should say >> >>>>>> why it is a non-issue. (It seems likely that excessive use of this >> >>>>>> option by an administrator could cause difficulties.) >> >>>>>> >> >>>>>> Nits: >> >>>>>> The introduction begins with the phrasing "The Neighbor Discovery >> >>>>>> (ICMPv6) protocol". While ND rides on top of ICMPv6, it is not > the same >> >>>>>> as ICMPv6. The parenthetical is misleading rather than helpful. > Please >> >>>>>> remove it. >> >>>>>> In contrast, it would be helpful if the beginning of the next >> >>>>>> sentence, "Extensions to the protocol defined in [RFC4191]" > actually >> >>>>>> included the words "Router Advertisement" in the text, since > that is >> >>>>>> what protocol is referred to without being named. >> >>>>>> >> >>>>>> It would seem a good idea to include a reference to the current >> >>>>>> specification of DHCPv6 the first time it is mentioned. >> >>>>>> >> >>>>>> It would be clearer (not technically different, but clearer) if the >> >>>>>> first and second sentence in section 4 each indicated what message >> >>>>>> (presumably request and response respectively) is being used to > carry >> >>>>>> this information. Even if obvious, it would also be good if the > second >> >>>>>> sentence referred to whatever option holder the response > message uses, >> >>>>>> in parallel with the construction of the first sentence. >> >>>>>> >> >>>>>> The text in section 4.1 as written makes it appear that routes are >> >>>>>> sent individually, rather than the description of the first part of >> >>>>>> section 4 or the actual description of the format of the >> >>>>>> OPTION_NEXT_HOP. (As written in 4.1, one is led to expect pairs of >> >>>>>> next-hops and routes, which is clearly not what you actually > intend.) >> >>>>>> >> >>>>>> Yours, >> >>>>>> Joel M. Halpern >> >>>>> >> >>>> >> > >> >