From jari.arkko@piuha.net Fri Oct 16 02:57:20 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C2943A67A1 for ; Fri, 16 Oct 2009 02:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPdvMtJB+Ui7 for ; Fri, 16 Oct 2009 02:57:19 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 8B0FF3A679F for ; Fri, 16 Oct 2009 02:57:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 6A782D4951 for ; Fri, 16 Oct 2009 12:57:22 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OcMUOrAqdt1 for ; Fri, 16 Oct 2009 12:57:20 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 76C82D4924 for ; Fri, 16 Oct 2009 12:57:19 +0300 (EEST) Message-ID: <4AD8437F.1040505@piuha.net> Date: Fri, 16 Oct 2009 12:57:19 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: dna@ietf.org References: <22664_1253197209_4AB24599_22664_4450033_1_2974_1253196965_4AB244A4_2974_4776891_1_20090917141501.F37C33A6B54@core3.amsl.com> In-Reply-To: <22664_1253197209_4AB24599_22664_4450033_1_2974_1253196965_4AB244A4_2974_4776891_1_20090917141501.F37C33A6B54@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dna] [DNA] I-D Action:draft-ietf-dna-simple-09.txt X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 09:57:20 -0000 I have reviewed the latest version and I believe it addressed all the issues that were brought up. I will now start the IETF Last Call. If there are any remaining issues, please bring them up there. Jari From jari.arkko@piuha.net Fri Oct 16 03:08:04 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4574A3A679F for ; Fri, 16 Oct 2009 03:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCHQVIICpEjM for ; Fri, 16 Oct 2009 03:08:03 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 662483A67A1 for ; Fri, 16 Oct 2009 03:08:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 19F58D49B3; Fri, 16 Oct 2009 13:08:07 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBS7AkyEq9vW; Fri, 16 Oct 2009 13:08:06 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id EE21CD4904; Fri, 16 Oct 2009 13:08:05 +0300 (EEST) Message-ID: <4AD84605.8050903@piuha.net> Date: Fri, 16 Oct 2009 13:08:05 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: DNA , dna@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dna] DNA working group completion X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 10:08:04 -0000 Now that the simple DNA document has been sent to IETF last call, I wanted to talk to you about the status of the working group. It has taken a long time, but we are finally there! I am sure there will be small issues in the IESG review, but I do not see any major problems. Thank you everyone who made this happen, Suresh you in particular have done a lot of work on this! But lets talk about the next steps. My inclination would be to say that we've completed our main task and that we can close the working group. A successful closure. Any follow-up documents (tentative, the experimental full protocol) can be submitted as individual submissions and I'd be happy to take them forward. But watching the energy level of the group dissipate over the years, I do not believe we have a reason to keep a formal working group alive. Obviously the mailing list should be kept alive. Thoughts? Jari From bernard_aboba@hotmail.com Fri Oct 16 04:27:17 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC3DF28C0FD for ; Fri, 16 Oct 2009 04:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.084 X-Spam-Level: X-Spam-Status: No, score=0.084 tagged_above=-999 required=5 tests=[AWL=0.824, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmNcteITMdpA for ; Fri, 16 Oct 2009 04:27:17 -0700 (PDT) Received: from blu0-omc2-s10.blu0.hotmail.com (blu0-omc2-s10.blu0.hotmail.com [65.55.111.85]) by core3.amsl.com (Postfix) with ESMTP id 1EBAF3A677D for ; Fri, 16 Oct 2009 04:27:17 -0700 (PDT) Received: from BLU137-DS1 ([65.55.111.72]) by blu0-omc2-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 04:27:21 -0700 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Jari Arkko'" , "'DNA'" , References: <25156_1255687743_4AD8463E_25156_5479872_1_4AD84605.8050903@piuha.net> In-Reply-To: <25156_1255687743_4AD8463E_25156_5479872_1_4AD84605.8050903@piuha.net> Date: Fri, 16 Oct 2009 04:27:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpOSLCLSW9t4Zb8Tl+HHRf85pCL6AACue8A Content-Language: en-us X-OriginalArrivalTime: 16 Oct 2009 11:27:21.0592 (UTC) FILETIME=[A086C780:01CA4E53] Subject: Re: [dna] [DNA] DNA working group completion X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 11:27:18 -0000 Sounds like a fine plan. -----Original Message----- From: owner-dna@ecselists.eng.monash.edu.au [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of Jari Arkko Sent: Friday, October 16, 2009 3:08 AM To: DNA; dna@ietf.org Subject: [DNA] DNA working group completion Now that the simple DNA document has been sent to IETF last call, I wanted to talk to you about the status of the working group. It has taken a long time, but we are finally there! I am sure there will be small issues in the IESG review, but I do not see any major problems. Thank you everyone who made this happen, Suresh you in particular have done a lot of work on this! But lets talk about the next steps. My inclination would be to say that we've completed our main task and that we can close the working group. A successful closure. Any follow-up documents (tentative, the experimental full protocol) can be submitted as individual submissions and I'd be happy to take them forward. But watching the energy level of the group dissipate over the years, I do not believe we have a reason to keep a formal working group alive. Obviously the mailing list should be kept alive. Thoughts? Jari From suresh.krishnan@ericsson.com Fri Oct 16 14:30:49 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15BCB3A68FF for ; Fri, 16 Oct 2009 14:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caquLLG7fjhw for ; Fri, 16 Oct 2009 14:30:48 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 42BFF3A657C for ; Fri, 16 Oct 2009 14:30:48 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n9GLUduW005105; Fri, 16 Oct 2009 16:30:41 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 16:29:54 -0500 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 16:29:53 -0500 Received: from [142.133.10.113] (147.117.20.212) by eusaamw0712.eamcs.ericsson.se (147.117.20.182) with Microsoft SMTP Server id 8.1.375.2; Fri, 16 Oct 2009 17:29:53 -0400 Message-ID: <4AD8E5C6.4070603@ericsson.com> Date: Fri, 16 Oct 2009 17:29:42 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Jari Arkko References: <25156_1255687743_4AD8463E_25156_5479872_1_4AD84605.8050903@piuha.net> In-Reply-To: <25156_1255687743_4AD8463E_25156_5479872_1_4AD84605.8050903@piuha.net> Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2009 21:29:53.0476 (UTC) FILETIME=[CCBA8040:01CA4EA7] Cc: DNA , "dna@ietf.org" Subject: Re: [dna] [DNA] DNA working group completion X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 21:30:49 -0000 Hi Jari, On 09-10-16 06:08 AM, Jari Arkko wrote: > Now that the simple DNA document has been sent to IETF last call, I > wanted to talk to you about the status of the working group. It has > taken a long time, but we are finally there! I am sure there will be > small issues in the IESG review, but I do not see any major problems. > Thank you everyone who made this happen, Suresh you in particular have > done a lot of work on this! > > But lets talk about the next steps. My inclination would be to say that > we've completed our main task and that we can close the working group. A > successful closure. Any follow-up documents (tentative, the experimental > full protocol) can be submitted as individual submissions and I'd be > happy to take them forward. But watching the energy level of the group > dissipate over the years, I do not believe we have a reason to keep a > formal working group alive. Obviously the mailing list should be kept alive. Sounds like a good plan. I fully support the idea of closing the WG :-). One thing I would like to be different is to progress the WG items (tentative and informational protocol) as WG documents to the IESG (as-is) immediately and then close the WG down. I feel that these documents have gone through a lot of working group review in their lifetime and by treating them as individual submissions they would appear to be immature and not adequately reviewed. Any followup can be done on the mailing list. What do you think? Thanks Suresh From jari.arkko@piuha.net Fri Oct 16 14:55:36 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2E053A6884 for ; Fri, 16 Oct 2009 14:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZMa6BqlEoti for ; Fri, 16 Oct 2009 14:55:36 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 0DD4C3A67AA for ; Fri, 16 Oct 2009 14:55:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B45F9D4936; Sat, 17 Oct 2009 00:55:39 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-UgALbcLUYM; Sat, 17 Oct 2009 00:55:38 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 0CE1FD4904; Sat, 17 Oct 2009 00:55:37 +0300 (EEST) Message-ID: <4AD8EBD9.7060008@piuha.net> Date: Sat, 17 Oct 2009 00:55:37 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Suresh Krishnan References: <25156_1255687743_4AD8463E_25156_5479872_1_4AD84605.8050903@piuha.net> <2972_1255728734_4AD8E65E_2972_3663297_1_4AD8E5C6.4070603@ericsson.com> In-Reply-To: <2972_1255728734_4AD8E65E_2972_3663297_1_4AD8E5C6.4070603@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DNA , "dna@ietf.org" Subject: Re: [dna] [DNA] DNA working group completion X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 21:55:36 -0000 Suresh, > One thing I would like to be different is to progress the WG items > (tentative and informational protocol) as WG documents to the IESG > (as-is) immediately and then close the WG down. I feel that these > documents have gone through a lot of working group review in their > lifetime and by treating them as individual submissions they would > appear to be immature and not adequately reviewed. Any followup can be > done on the mailing list. What do you think? I don't think individual submissions imply that the documents are immature. The reviewers need to understand the history and status of each document in any case, be it from the working group or individual. However, I don't that matters much. Nor does it matter how many years they have been in the process. What matters is whether the said documents are ready. Are they? As ready as the simple DNA document is? Jari From suresh.krishnan@ericsson.com Fri Oct 16 15:23:28 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E7543A6814 for ; Fri, 16 Oct 2009 15:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGucGb9H4zWa for ; Fri, 16 Oct 2009 15:23:27 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id B76323A6405 for ; Fri, 16 Oct 2009 15:23:27 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n9GMNQsZ031190; Fri, 16 Oct 2009 17:23:27 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 17:23:01 -0500 Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 17:23:01 -0500 Received: from [142.133.10.113] (147.117.20.212) by eusaamw0711.eamcs.ericsson.se (147.117.20.179) with Microsoft SMTP Server id 8.1.375.2; Fri, 16 Oct 2009 18:23:00 -0400 Message-ID: <4AD8F239.3090006@ericsson.com> Date: Fri, 16 Oct 2009 18:22:49 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Jari Arkko References: <25156_1255687743_4AD8463E_25156_5479872_1_4AD84605.8050903@piuha.net> <2972_1255728734_4AD8E65E_2972_3663297_1_4AD8E5C6.4070603@ericsson.com> <25144_1255730168_4AD8EBF8_25144_89518_1_4AD8EBD9.7060008@piuha.net> In-Reply-To: <25144_1255730168_4AD8EBF8_25144_89518_1_4AD8EBD9.7060008@piuha.net> Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2009 22:23:01.0320 (UTC) FILETIME=[38D4E480:01CA4EAF] Cc: DNA , "dna@ietf.org" Subject: Re: [dna] [DNA] DNA working group completion X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 22:23:28 -0000 Hi Jari, On 09-10-16 05:55 PM, Jari Arkko wrote: > However, I don't that matters much. Nor does it matter how many years > they have been in the process. What matters is whether the said > documents are ready. Are they? As ready as the simple DNA document is? Makes sense. I will talk to the authors to see how comfortable they feel about the documents. Thanks Suresh From bernard_aboba@hotmail.com Tue Oct 20 13:08:49 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC3933A67D8; Tue, 20 Oct 2009 13:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[AWL=1.601, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EToSWiFAGMl1; Tue, 20 Oct 2009 13:08:46 -0700 (PDT) Received: from blu0-omc2-s8.blu0.hotmail.com (blu0-omc2-s8.blu0.hotmail.com [65.55.111.83]) by core3.amsl.com (Postfix) with ESMTP id E4A043A67B3; Tue, 20 Oct 2009 13:08:42 -0700 (PDT) Received: from BLU137-W17 ([65.55.111.71]) by blu0-omc2-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 13:08:51 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_469e98b6-16d9-49e9-9218-50394412ed0c_" X-Originating-IP: [70.58.72.16] From: Bernard Aboba To: , , Date: Tue, 20 Oct 2009 13:08:51 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 20 Oct 2009 20:08:51.0614 (UTC) FILETIME=[247C3BE0:01CA51C1] Subject: [dna] Review of draft-ietf-dna-simple-09 X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 20:08:49 -0000 --_469e98b6-16d9-49e9-9218-50394412ed0c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Review of draft-ietf-dna-simple-09 I have reviewed draft-ietf-dna-simple. Overall=2C I believe this document = still contains significant technical issues that need to be addressed before it would be suitable for publication as a Proposed Standard. In particular= =2C the version of the document sent to IETF last call does not incorporate fix= es to issues listed in the WG issue tracker as "fixed". This raises the possi= bility that changes from WG last call were not properly applied or even that the wrong= =20 version of the document may have been sent to IETF last call.=20 Given the potential problems=2C a careful check needs to be made of the cha= nges between -08 and -09 to make sure that resolutions to WG last call and AD=20 review comments were properly applied.=20 Technical Abstract This document provides simple procedures for detecting network attachment in IPv6 hosts=2C and procedures for routers to support such services. [BA] My understanding was that the goal of Simple DNA was to avoid=20 changes to routers. Given that=2C what router procedure need to be specified?=20 Section 2.4 2.4. DNA Roles Detecting Network Attachment is performed by hosts by sending IPv6 neighbor discovery and router discovery messages to routers after connecting to a network. It is desirable that routers adopt procedures which allow for fast unicast Router Advertisement (RA) messages. Routers that follow the standard neighbor discovery procedure described in [RFC4861] will delay the router advertisement by a random period between 0 and MAX_RA_DELAY_TIME (defined to be 500ms) as described in Section 6.2.6 of [RFC4861]. This delay can be significant and may result in service disruption. Please note that support for fast unicast RAs is not necessary since the simple dna procedure can continue to work using the NS/NA exchange=2C which will complete earlier than the RA arrives. The host detects that the link-layer may have changed=2C and then simultaneously probes the network with Router Solicitations (RSs) and Neighbor Solicitations (NSs). The host uses advertisements to determine if the routers it currently has configured are still available. Additionally=2C on links with no statelessly configured addresses=2C the host may make use of DHCPv6 procedures to identify an operable address. [BA] This paragraph does not describe the situations in which=20 RA delays will be significant. Clarity would be enhanced by describing this.=20 The description of the role of DHCPv6 in this section appears to conflict with the description in Section 4.6. Section 4.6 discusses=20 use of Neighbor Discovery probing in parallel with DHCPv6 probing=2C=20 implying that RS probing is not used. This section implies that=20 DHCPv6 probing is only done after a combination of RS and NS=20 probing does not result in a statelessly configured address. =20 Perhaps the best way to explain the interaction is to think of=20 simple DNA as independent of DHCPv6. That is=2C implementation=20 of simple DNA does not change the DHCPv6 state machine or timers=3B =20 implementations continue to send the same DHCPv6 packets in the=20 same situations and with the same timing as they did without=20 simple DNAv6. The only new wrinkle is the potential for conflicts between simple DNA and DHCPv6=2C in which case the information=20 obtained via DHCPv6 wins.=20 This is true regardless of whether an implementation waits for an RA before deciding whether to use DHCPv6=2C or whether it sends DHCPv6 packets regardless of the state of the 'M' and 'O' bits in the RA. =20 My suggested text is as follows:=20 2.4. DNA Overview Detecting Network Attachment is performed by hosts after=20 detecting a link-layer "up" indication. The host simultaneously sends multicast Router Solicitations (RSs) and unicast Neighbor Solicitations (NSs) in order to determine whether previously encountered routers are present on the link.=20 Hosts implementing simple DNA may also send DHCPv6 packets=2C as described in Section 4.6. Since simple DNA does not modify the DHCPv6 protocol or state machine=2C the operation of DHCPv6 is unchanged.=20 Routers that follow the standard neighbor discovery procedure=20 described in [RFC4861] will delay the router advertisement by a=20 random period between 0 and MAX_RA_DELAY_TIME (defined to be 500ms)=20 as described in Section 6.2.6 of [RFC4861]. Hosts implementing=20 simple DNA can detect the presence of a previously encountered=20 router using unicast Neighbor Solicitations. As a result=2C where=20 the host with a valid configuration is returning to a previously=20 encountered link=2C delays in the sending of a Router Advertisement=20 (RA) will not delay configuration as long as NS probing is successful. However in situations where the host is attaching to a link for the first time=2C or where it does not have a valid IP address on the link=2C it will be dependent on the receipt of an RA for stateless auto-configuration. In these situations delays in the receipt of an RA can be significant and may result in service disruption.=20 As a result=2C in addition to implementing simple DNA=2C it is=20 desirable that routers adopt procedures which allow for fast unicast Router Advertisement (RA) messages. Section 4.5.1 The probing node SHOULD NOT include the Source link-layer address option in the probe messages. [BA] In looking through versions of the document=2C it appears that this t= ext=20 changed between -08 and -09=2C but it is not clear why. Was this the resul= t of an editorial error=2C or was it made in response to the AD review?=20 My recommendation is that the -08 text be restored: The probing node SHOULD include a Source link-layer address option in the probe messages if the address was obtained using DHCPv6 and the lease has not expired. Otherwise the probing node SHOULD NOT include the Source link-layer address option in the probe messages. The existing text is problematic since if the SSLAO is not included=2C=20 then the ND cache on the router will not be seeded=2C and return reachabili= ty=20 will not be enabled. This significantly impacts the utility of simple DNA= =2C=20 which in the v4 version was able to both configuration configuration and=20 establish bi-directional reachability in a single step. Since the NS is se= nt to a unicast MAC and IP address only when the host has a valid IP address= =2C I don't think there is a danger of cache pollution.=20 Section 4.5.2 The probing node SHOULD include a Source link-layer address option in the probe messages if the address was obtained using DHCPv6 and the lease has not expired. Otherwise the probing node SHOULD NOT include the Source link-layer address option in the probe messages. [BA] As listed in Issue #15 (listed as fixed in the tracker)=2C the text was to be changed to indicate that the SLLAO should not be included in the Router Advertisement: See http://webcamserver.eng.monash.edu.au/~warchive/dna/2009-09/msg00003.ht= ml Although this issue was resolved as fixed=2C the fix does not appear to hav= e=20 been applied in the document sent to IETF last call. Was the correct versi= on=20 of the document sent to WG last call?=20 The existing text does not make sense because a single router solicitation = is sent=2C not one for each address. Since the router solicitation is sent once via multicast=2C it is not clear to me how the advice in this paragrap= h can be implemented=2C since until simple DNA is completed=2C the host canno= t know which address (if any) will turn out to be valid.=20 Section 4.6 Where the host has acquired addresses from DHCPv6 or the host does not have a global prefix=2C it MAY prefer to use DHCPv6 probe messages in parallel with the Neighbor Discovery probing. The DHCPv6 probing procedures described in this document do not imply any changes to the DHCPv6 protocol or state machine. [BA] The first sentence appears to imply that DHCPv6 probing is done instea= d of sending a multicast RS. I don't think this is what was intended.=20 Rather=2C I think what this section is trying to communicate is that implem= entation of simple DNA is largely orthogonal to DHCPv6. If a DHCPv6 implementation = decides whether to send DHCPv6 packets based on the contents of the RA=2C then it w= ill continue to do that after implementing DNA. If it sends DHCPv6 packets regardless o= f the=20 contents of the RA=2C then it will continue to do that. Since the timing= =2C state machine and contents of DHCPv6 packets is unaffected=2C simple DNA continue= s to=20 guarantee that it will "do no harm" with respect to performance=2C regardle= ss of the details of the DHCPv6 implementation.=20 Here is my recommended rewrite of Section 4.6: 4.6. DHCPv6 operation Simple DNA does not require a host to implement DHCPv6=2C nor does it=20 imply any changes to the DHCPv6 protocol or state machine.=20 Hosts MAY attempt to obtain IPv6 configuration via DHCPv6=20 in parallel with simple DNA probing. This ensures that the=20 simple DNA procedure will not result in additional delay in=20 the case where reachability tests fail=2C or where a DHCPv6 exchange=20 completes more quickly than the reachability tests. =20 In situations where both simple DNA and DHCPv6 are used on the same link= =2C=20 it is possible that simple DNA probing will complete successfully=2C and then DHCPv6 will complete later with a different result. If this happens=2C the procedure described in Section 4.7.1 are utilized.=20 Where the host attempts to obtain IPv6 configuration in parallel with simple DNA=2C on receiving a link-layer "up" indication=2C it sends a DHCPv6 SOLICIT to All_DHCP_Relay_Agents_and_Servers. This message contains an Identity Association for either a Temporary Address (IA_TA) or Non-Temporary Address (IA_NA) [RFC3315]. Where an existing valid address is being tested for operability=2C this address should be placed in the Identity Association's IAADDR element=2C and the DUID associated with that address should be copied to the DHCP SOLICIT from the SDAT. In order to quickly acquire a new address in the case that link change has occurred=2C this SOLICIT message MAY contain the Rapid- Commit option. Where the Rapid-Commit option has not been used=2C a present DHCP server will respond with an ADVERTISE message. The IP address contained in the Identity Association (IA_TA or IA_NA) will contain an IP Address which is operable for the link. Where Rapid-Commit option has been sent=2C a DHCPv6 server will respond with REPLY. In addition to being operable=2C this address is allocated to the host for the lease duration indicated in the Identity Association. Section 5 It probably should be noted that the pseudo code does not include sending of DHCPv6 packets=2C since that is orthogonal to simple DNA.=20 Appendix A Hence agressive retransmissions are mandated. [BA] "mandated" -> "necessary". o Another issue comes up when the host moves between two networks=2C one where manual addressing is being used (say NET1)and the other where dynamic addressing (DHCPv6) is being used (say NET2). When the host moves to NET1 from NET2 it tries to confirm both the manual address and the dynamic address in parallel. If the probe for the manually assigned address is lost=2C the DHCPv6 probe will succeed and the host will incorrectly end up using the DHCPv6 assigned address (from NET2) on NET1. [BA] Since the manual address is only supposed to be used on NET1=2C this example is not actually a problem -- it is valid for the host to use=20 a DHCPv6 assigned address if it moves from NET1 to NET2. The problem occurs if DHCPv6 is enabled on NET1 and the host ends up using a=20 DHCPv6 (or stateless autoconfig) address instead of a static one=20 when it connects to NET1. Suggested change: o Another issue comes up when the host moves between two networks=2C one where manual addressing is being used (say NET1)and the other where dynamic addressing (stateless autoconfig or DHCPv6) is=20 being used (say NET2). Since the host can obtain a dynamic address in some situations=2C it will need to send simple DNA probes and may also engage in a DHCPv6 exchange. In a situation where the host moves to NET1 and the NS probes are lost and in addition an RA is not received=2C the host will not be able to confirm that it attached to NET1=2C and therefore that it should use the manual configuration for that network. As a result=2C if DHCPv6 is enabled o= n NET1=2C then the host could mistakenly obtain a dynamic address and configuration instead of using the manual configuration. To=20 prevent this problem=2C simple DNA probing needs to continue even after the DHCPv6 exchange has completed=2C and DNA probes need to take precedence over DHCPv6=2C contrary to the advice provided in Section 4.7.1.=20 Editorial Section 2 Hosts require procedures to simply and reliably identify if they have moved to a different IP network to the one which they have been recently connected.=20 [BA] "to the one which" -> "than the one to which" Section 2.1 The goal of this document is to specify a simple procedure for detecting network attachment (Simple DNA) that has the following characteristics. o Routers do not have to be modified to support this scheme. o Handle only the simplest and most likely use cases. o Work at least as quickly as standard neighbor discovery. [BA] The second and third bullets do not have a parallel grammatical structure. How about this?=20 The goal of this document is to specify a simple procedure for detecting network attachment (Simple DNA) that has the following characteristics: o Routers do not have to be modified to support this scheme=3B o The most common use cases are optimized=3B o In the worst case=2C detection latency is equal to that of=20 existing schemes so that performance is never degraded=3B=20 =20 Section 4.7.1 It is possible that the DHCPv6 based probes and the neighbor discovery based probes complete with conflicting results. In this case=2C the host SHOULD use the following rules to determine the final result. o If the DHCPv6 exchange was authenticated=2C use the result from the DHCPv6 probe. o If the DHCPv6 exchange was not authenticated and the neighbor discovery exchange was protected by SEND [RFC3971]=2C use the result from the neighbor discovery probe. o If both the DHCPv6 and neighbor discovery exchanges were not authenticated=2C use the result from the DHCPv6 probe [BA] The use of the term "DHCPv6 probe" is a bit confusing in that it seems to imply that DHCPv6 operates differently with simple DNA. My recommendati= on is to eliminate use of this term=2C as follows: It is possible that DHCPv6 exchanges and the neighbor discovery based probes complete with conflicting results. In this case=2C the host SHOULD use the following rules to determine the final result: o If the DHCPv6 exchange was authenticated=2C use the result from DHCPv6. o If the DHCPv6 exchange was not authenticated and the neighbor discovery exchange was protected by SEND [RFC3971]=2C use the result from the neighbor discovery probe. o If both the DHCPv6 and neighbor discovery exchanges were not authenticated=2C use the result from DHCPv6. Section 4.9 The first paragraph isn't about retransmission=2C so it might be better to move it to section 4.7.1.=20 = --_469e98b6-16d9-49e9-9218-50394412ed0c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Review of draft-ietf-dna-simple-09

I have reviewed draft-ietf-dna-si= mple. =3B Overall=2C I believe this document still
contains signific= ant technical issues that need to be addressed before
it would be suitab= le for publication as a Proposed Standard. =3B In particular=2C
the = version of the document sent to IETF last call does not incorporate fixesto issues listed in the WG issue tracker as "fixed". =3B This raises = the possibility that
changes from WG last call were not properly applied= or even that the wrong
version of the document may have been sent to I= ETF last call.

Given the potential problems=2C a careful check need= s to be made of the changes
between -08 and -09 to make sure that resolu= tions to WG last call and AD
review comments were properly applied.
Technical

Abstract

 =3B =3B This document provid= es simple procedures for detecting network
 =3B =3B attachment i= n IPv6 hosts=2C and procedures for routers to support such
 =3B = =3B services.

[BA] My understanding was that the goal of Simple DNA = was to avoid
changes to routers. =3B Given that=2C what router proc= edure need to be
specified?

Section 2.4

2.4. DNA Roles

 =3B =3B Detecting Network Attachment is performed by host= s by sending IPv6
 =3B =3B neighbor discovery and router discove= ry messages to routers after
 =3B =3B connecting to a network.
 =3B =3B It is desirable that routers adopt procedures which = allow for fast
 =3B =3B unicast Router Advertisement (RA) messag= es. =3B Routers that follow the
 =3B =3B standard neighbor d= iscovery procedure described in [RFC4861] will
 =3B =3B delay th= e router advertisement by a random period between 0 and
 =3B =3B= MAX_RA_DELAY_TIME (defined to be 500ms) as described in Section 6.2.6
&= nbsp=3B =3B of [RFC4861]. =3B This delay can be significant and may= result in
 =3B =3B service disruption. =3B Please note that= support for fast unicast RAs is
 =3B =3B not necessary since th= e simple dna procedure can continue to work
 =3B =3B using the N= S/NA exchange=2C which will complete earlier than the RA
 =3B = =3B arrives.

 =3B =3B The host detects that the link-layer m= ay have changed=2C and then
 =3B =3B simultaneously probes the n= etwork with Router Solicitations (RSs) and
 =3B =3B Neighbor Sol= icitations (NSs). =3B The host uses advertisements to
 =3B = =3B determine if the routers it currently has configured are still
 = =3B =3B available.

 =3B =3B Additionally=2C on links wit= h no statelessly configured addresses=2C the
 =3B =3B host may m= ake use of DHCPv6 procedures to identify an operable
 =3B =3B ad= dress.

[BA] This paragraph does not describe the situations in which=
RA delays will be significant. =3B Clarity would be enhanced bydescribing this.

The description of the role of DHCPv6 in this sec= tion appears to
conflict with the description in Section 4.6. =3B Se= ction 4.6 discusses
use of Neighbor Discovery probing in parallel with = DHCPv6 probing=2C
implying that RS probing is not used. =3B This se= ction implies that
DHCPv6 probing is only done after a combination of R= S and NS
probing does not result in a statelessly configured address.&n= bsp=3B

Perhaps the best way to explain the interaction is to think = of
simple DNA as independent of DHCPv6. =3B That is=2C implementati= on
of simple DNA does not change the DHCPv6 state machine or timers=3B&= nbsp=3B
implementations continue to send the same DHCPv6 packets in the=
same situations and with the same timing as they did without
simpl= e DNAv6. =3B The only new wrinkle is the potential for conflicts
bet= ween simple DNA and DHCPv6=2C in which case the information
obtained vi= a DHCPv6 wins.

This is true regardless of whether an implementation= waits for an
RA before deciding whether to use DHCPv6=2C or whether it = sends
DHCPv6 packets regardless of the state of the 'M' and 'O' bits
= in the RA. =3B

My suggested text is as follows:

2.4. DN= A Overview

 =3B =3B Detecting Network Attachment is performe= d by hosts after
 =3B =3B detecting a link-layer "up" indicatio= n. =3B The host simultaneously
 =3B =3B sends multicast Rout= er Solicitations (RSs) and unicast Neighbor
 =3B =3B Solicitatio= ns (NSs) in order to determine whether previously
 =3B =3B encou= ntered routers are present on the link.

 =3B =3B Hosts impl= ementing simple DNA may also send DHCPv6 packets=2C
 =3B =3B as = described in Section 4.6. =3B Since simple DNA does not
 =3B&nbs= p=3B modify the DHCPv6 protocol or state machine=2C the operation
 = =3B =3B of DHCPv6 is unchanged.

 =3B =3B Routers that f= ollow the standard neighbor discovery procedure
 =3B =3B descri= bed in [RFC4861] will delay the router advertisement by a
 =3B = =3B random period between 0 and MAX_RA_DELAY_TIME (defined to be 500ms)  =3B =3B as described in Section 6.2.6 of [RFC4861]. =3B Hosts= implementing
 =3B =3B simple DNA can detect the presence of a = previously encountered
 =3B =3B router using unicast Neighbor S= olicitations. =3B As a result=2C where
 =3B =3B the host wi= th a valid configuration is returning to a previously
 =3B =3B = encountered link=2C delays in the sending of a Router Advertisement
&nb= sp=3B =3B (RA) will not delay configuration as long as NS probing is =3B =3B successful. =3B However in situations where the host = is
 =3B =3B attaching to a link for the first time=2C or where i= t does not
 =3B =3B have a valid IP address on the link=2C it wi= ll be dependent
 =3B =3B on the receipt of an RA for stateless a= uto-configuration. =3B In
 =3B =3B these situations delays i= n the receipt of an RA can be significant
 =3B =3B and may resul= t in service disruption.

 =3B =3B As a result=2C in additio= n to implementing simple DNA=2C it is
 =3B =3B desirable that r= outers adopt procedures which allow for fast
 =3B =3B unicast Ro= uter Advertisement (RA) messages.

Section 4.5.1

 =3B = =3B The probing node SHOULD NOT include the Source link-layer address
&n= bsp=3B =3B option in the probe messages.

[BA] =3B In looking= through versions of the document=2C it appears that this text
changed = between -08 and -09=2C but it is not clear why. =3B Was this the result=
of an editorial error=2C or was it made in response to the AD review? <= br>My recommendation is that the -08 text be restored:

 =3B = =3B The probing node SHOULD include a Source link-layer address option in =3B =3B the probe messages if the address was obtained using DHC= Pv6 and the
 =3B =3B lease has not expired. =3B Otherwise th= e probing node SHOULD NOT include
 =3B =3B the Source link-layer= address option in the probe messages.

The existing text is problema= tic since if the SSLAO is not included=2C
then the ND cache on the rout= er will not be seeded=2C and return reachability
will not be enabled. T= his significantly impacts the utility of simple DNA=2C
which in the v4 = version was able to both configuration configuration and
establish bi-d= irectional reachability in a single step. =3B Since the NS is sent
t= o a unicast MAC and IP address only when the host has a valid IP address=2C=
I don't think there is a danger of cache pollution.

Section 4.5= .2

 =3B =3B The probing node SHOULD include a Source link-la= yer address option in
 =3B =3B the probe messages if the address= was obtained using DHCPv6 and the
 =3B =3B lease has not expire= d. =3B Otherwise the probing node SHOULD NOT include
 =3B = =3B the Source link-layer address option in the probe messages.

[BA]= As listed in Issue #15 (listed as fixed in the tracker)=2C
the text was= to be changed to indicate that the SLLAO should not be
included in the = Router Advertisement:
See http://webcamserver.eng.monash.edu.au/~warchiv= e/dna/2009-09/msg00003.html

Although this issue was resolved as fixe= d=2C the fix does not appear to have
been applied in the document sent = to IETF last call. =3B Was the correct version
of the document sent= to WG last call?

The existing text does not make sense because a s= ingle router solicitation is
sent=2C not one for each address. =3B S= ince the router solicitation is sent
once via multicast=2C it is not cle= ar to me how the advice in this paragraph
can be implemented=2C since un= til simple DNA is completed=2C the host cannot know
which address (if an= y) will turn out to be valid.

Section 4.6

 =3B =3B W= here the host has acquired addresses from DHCPv6 or the host does
 = =3B =3B not have a global prefix=2C it MAY prefer to use DHCPv6 probe m= essages
 =3B =3B in parallel with the Neighbor Discovery probing= . =3B The DHCPv6 probing
 =3B =3B procedures described in th= is document do not imply any changes to the
 =3B =3B DHCPv6 prot= ocol or state machine.

[BA] The first sentence appears to imply that= DHCPv6 probing is done instead
of sending a multicast RS. =3B I don= 't think this is what was intended.

Rather=2C I think what this sec= tion is trying to communicate is that implementation
of simple DNA is la= rgely orthogonal to DHCPv6. =3B If a DHCPv6 implementation decides
w= hether to send DHCPv6 packets based on the contents of the RA=2C then it wi= ll continue
to do that after implementing DNA. =3B If it sends DHCPv= 6 packets regardless of the
contents of the RA=2C then it will continue= to do that. =3B Since the timing=2C state
machine and contents of D= HCPv6 packets is unaffected=2C simple DNA continues to
guarantee that i= t will "do no harm" with respect to performance=2C regardless of the
det= ails of the DHCPv6 implementation.

Here is my recommended rewrite o= f Section 4.6:

4.6. DHCPv6 operation

 =3B =3B Simple = DNA does not require a host to implement DHCPv6=2C nor does it
 =3B=  =3B imply any changes to the DHCPv6 protocol or state machine.
&nb= sp=3B =3B Hosts MAY attempt to obtain IPv6 configuration via DHCPv6  =3B =3B in parallel with simple DNA probing. =3B This ensures= that the
 =3B =3B simple DNA procedure will not result in addi= tional delay in
 =3B =3B the case where reachability tests fail= =2C or where a DHCPv6 exchange
 =3B =3B completes more quickly = than the reachability tests. =3B =3B =3B

 =3B = =3B In situations where both simple DNA and DHCPv6 are used on the same lin= k=2C
 =3B =3B it is possible that simple DNA probing will compl= ete successfully=2C
 =3B =3B and then DHCPv6 will complete later= with a different result. =3B If this
 =3B =3B happens=2C th= e procedure described in Section 4.7.1 are utilized.

 =3B = =3B Where the host attempts to obtain IPv6 configuration in parallel with =3B =3B simple DNA=2C on receiving a link-layer "up" indication= =2C it
 =3B =3B sends a DHCPv6 SOLICIT to All_DHCP_Relay_Agents_= and_Servers. =3B This
 =3B =3B message contains an Identity = Association for either a Temporary
 =3B =3B Address (IA_TA) or N= on-Temporary Address (IA_NA) [RFC3315]. =3B Where an
 =3B = =3B existing valid address is being tested for operability=2C this address<= br> =3B =3B should be placed in the Identity Association's IAADDR e= lement=2C and
 =3B =3B the DUID associated with that address sho= uld be copied to the DHCP
 =3B =3B SOLICIT from the SDAT.
 =3B =3B In order to quickly acquire a new address in the case tha= t link
 =3B =3B change has occurred=2C this SOLICIT message MAY = contain the Rapid-
 =3B =3B Commit option.

 =3B = =3B Where the Rapid-Commit option has not been used=2C a present DHCP
&n= bsp=3B =3B server will respond with an ADVERTISE message. =3B The I= P address
 =3B =3B contained in the Identity Association (IA_TA = or IA_NA) will contain
 =3B =3B an IP Address which is operable = for the link.

 =3B =3B Where Rapid-Commit option has been se= nt=2C a DHCPv6 server will respond
 =3B =3B with REPLY. =3B = In addition to being operable=2C this address is allocated
 =3B = =3B to the host for the lease duration indicated in the Identity
 = =3B =3B Association.

Section 5

It probably should be note= d that the pseudo code does not include
sending of DHCPv6 packets=2C sin= ce that is orthogonal to simple DNA.

Appendix A

Hence agress= ive retransmissions are mandated.

[BA] "mandated" ->=3B "necessary= ".

 =3B =3B o =3B Another issue comes up when the host m= oves between two networks=2C
 =3B =3B =3B =3B =3B on= e where manual addressing is being used (say NET1)and the other
 =3B=  =3B =3B =3B =3B where dynamic addressing (DHCPv6) is being= used (say NET2). =3B When
 =3B =3B =3B =3B =3B = the host moves to NET1 from NET2 it tries to confirm both the
 =3B&n= bsp=3B =3B =3B =3B manual address and the dynamic address in pa= rallel. =3B If the probe
 =3B =3B =3B =3B =3B fo= r the manually assigned address is lost=2C the DHCPv6 probe will
 = =3B =3B =3B =3B =3B succeed and the host will incorrectly e= nd up using the DHCPv6
 =3B =3B =3B =3B =3B assigned= address (from NET2) on NET1.

[BA] Since the manual address is only = supposed to be used on NET1=2C this
 =3B =3B =3B =3B exa= mple is not actually a problem -- it is valid for the host to use
 = =3B =3B =3B =3B a DHCPv6 assigned address if it moves from NET1= to NET2. =3B The problem
 =3B =3B =3B =3B occurs if= DHCPv6 is enabled on NET1 and the host ends up using a
 =3B = =3B =3B =3B DHCPv6 (or stateless autoconfig) address instead of a s= tatic one
 =3B =3B =3B =3B when it connects to NET1.&nb= sp=3B Suggested change:


 =3B =3B o =3B Another issue= comes up when the host moves between two networks=2C
 =3B =3B&n= bsp=3B =3B =3B one where manual addressing is being used (say NET1)= and the other
 =3B =3B =3B =3B =3B where dynamic add= ressing (stateless autoconfig or DHCPv6) is
 =3B =3B =3B&nb= sp=3B =3B being used (say NET2). =3B Since the host can obtain a dy= namic address
 =3B =3B =3B =3B =3B in some situation= s=2C it will need to send simple DNA probes and
 =3B =3B =3B=  =3B =3B may also engage in a DHCPv6 exchange. =3B In a situati= on where the
 =3B =3B =3B =3B =3B host moves to NET1= and the NS probes are lost and in addition an
 =3B =3B =3B&= nbsp=3B =3B RA is not received=2C the host will not be able to confirm = that it
 =3B =3B =3B =3B =3B attached to NET1=2C and= therefore that it should use the manual
 =3B =3B =3B = =3B =3B configuration for that network. As a result=2C if DHCPv6 is ena= bled on
 =3B =3B =3B =3B =3B NET1=2C then the host c= ould mistakenly obtain a dynamic address and
 =3B =3B =3B&nb= sp=3B =3B configuration instead of using the manual configuration. = =3B To
 =3B =3B =3B =3B =3B prevent this problem=2C= simple DNA probing needs to continue even
 =3B =3B =3B = =3B =3B after the DHCPv6 exchange has completed=2C and DNA probes need = to
 =3B =3B =3B =3B =3B take precedence over DHCPv6= =2C contrary to the advice
 =3B =3B =3B =3B =3B prov= ided in Section 4.7.1.

Editorial

Section 2

 =3B&n= bsp=3B Hosts require procedures to simply and reliably identify if they hav= e
 =3B =3B moved to a different IP network to the one which they= have been
 =3B =3B recently connected.

[BA] "to the one= which" ->=3B "than the one to which"

Section 2.1

 =3B&= nbsp=3B The goal of this document is to specify a simple procedure for
&= nbsp=3B =3B detecting network attachment (Simple DNA) that has the foll= owing
 =3B =3B characteristics.

 =3B =3B o = =3B Routers do not have to be modified to support this scheme.

 = =3B =3B o =3B Handle only the simplest and most likely use cases.
 =3B =3B o =3B Work at least as quickly as standard neigh= bor discovery.


[BA] The second and third bullets do not have a p= arallel grammatical
structure. =3B How about this?

 =3B&= nbsp=3B The goal of this document is to specify a simple procedure for
&= nbsp=3B =3B detecting network attachment (Simple DNA) that has the foll= owing
 =3B =3B characteristics:

 =3B =3B o = =3B Routers do not have to be modified to support this scheme=3B

&nb= sp=3B =3B o =3B The most common use cases are optimized=3B

&= nbsp=3B =3B o =3B In the worst case=2C detection latency is equal t= o that of
 =3B =3B =3B =3B =3B existing schemes so = that performance is never degraded=3B
 =3B =3B =3B =3B&= nbsp=3B

Section 4.7.1

 =3B =3B It is possible that t= he DHCPv6 based probes and the neighbor
 =3B =3B discovery based= probes complete with conflicting results. =3B In this
 =3B = =3B case=2C the host SHOULD use the following rules to determine the final<= br> =3B =3B result.

 =3B =3B o =3B If the DHCPv6= exchange was authenticated=2C use the result from the
 =3B =3B&= nbsp=3B =3B =3B DHCPv6 probe.

 =3B =3B o =3B If = the DHCPv6 exchange was not authenticated and the neighbor
 =3B = =3B =3B =3B =3B discovery exchange was protected by SEND [RFC39= 71]=2C use the result
 =3B =3B =3B =3B =3B from the = neighbor discovery probe.

 =3B =3B o =3B If both the DHC= Pv6 and neighbor discovery exchanges were not
 =3B =3B =3B&n= bsp=3B =3B authenticated=2C use the result from the DHCPv6 probe
[BA] The use of the term "DHCPv6 probe" is a bit confusing in that it seem= s
to imply that DHCPv6 operates differently with simple DNA. =3B My = recommendation
is to eliminate use of this term=2C as follows:

&n= bsp=3B =3B It is possible that DHCPv6 exchanges and the neighbor
&nb= sp=3B =3B discovery based probes complete with conflicting results.&nbs= p=3B In this
 =3B =3B case=2C the host SHOULD use the following = rules to determine the final
 =3B =3B result:

 =3B&nb= sp=3B o =3B If the DHCPv6 exchange was authenticated=2C use the result = from
 =3B =3B =3B =3B =3B DHCPv6.

 =3B&nb= sp=3B o =3B If the DHCPv6 exchange was not authenticated and the neighb= or
 =3B =3B =3B =3B =3B discovery exchange was prote= cted by SEND [RFC3971]=2C use the result
 =3B =3B =3B = =3B =3B from the neighbor discovery probe.

 =3B =3B o&nb= sp=3B If both the DHCPv6 and neighbor discovery exchanges were not
 = =3B =3B =3B =3B =3B authenticated=2C use the result from DH= CPv6.

Section 4.9

The first paragraph isn't about retransmiss= ion=2C so it might be better to
move it to section 4.7.1.

= = --_469e98b6-16d9-49e9-9218-50394412ed0c_-- From jari.arkko@piuha.net Tue Oct 20 14:10:33 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCA2E28C159 for ; Tue, 20 Oct 2009 14:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBGZ6MFhIT8h for ; Tue, 20 Oct 2009 14:10:32 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id AE34828C142 for ; Tue, 20 Oct 2009 14:10:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 66A47D492A; Wed, 21 Oct 2009 00:10:39 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXv6oMNe-rXs; Wed, 21 Oct 2009 00:10:38 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id A8B05D491C; Wed, 21 Oct 2009 00:10:38 +0300 (EEST) Message-ID: <4ADE274E.3090700@piuha.net> Date: Wed, 21 Oct 2009 00:10:38 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Suresh Krishnan References: <25156_1255687743_4AD8463E_25156_5479872_1_4AD84605.8050903@piuha.net> <2972_1255728734_4AD8E65E_2972_3663297_1_4AD8E5C6.4070603@ericsson.com> <25144_1255730168_4AD8EBF8_25144_89518_1_4AD8EBD9.7060008@piuha.net> <4AD8F239.3090006@ericsson.com> In-Reply-To: <4AD8F239.3090006@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DNA , "dna@ietf.org" Subject: Re: [dna] [DNA] DNA working group completion X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 21:10:33 -0000 > Makes sense. I will talk to the authors to see how comfortable they > feel about the documents. Was there a response from the authors? (And they could speak here on the list, too, I suppose...) Jari From suresh.krishnan@ericsson.com Wed Oct 21 07:33:23 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7E963A677D; Wed, 21 Oct 2009 07:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tekLSxSixESJ; Wed, 21 Oct 2009 07:33:21 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id B8E1F3A68A6; Wed, 21 Oct 2009 07:33:21 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n9LEXRSa011309; Wed, 21 Oct 2009 09:33:27 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 09:33:24 -0500 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 09:33:23 -0500 Received: from [142.133.10.113] (147.117.20.213) by eusaamw0712.eamcs.ericsson.se (147.117.20.182) with Microsoft SMTP Server id 8.1.375.2; Wed, 21 Oct 2009 10:33:23 -0400 Message-ID: <4ADF1B9F.5060607@ericsson.com> Date: Wed, 21 Oct 2009 10:33:03 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2009 14:33:23.0915 (UTC) FILETIME=[71DAD9B0:01CA525B] Cc: "dna@ietf.org" , "ops-dir@ietf.org" , "ietf@ietf.org" Subject: Re: [dna] Review of draft-ietf-dna-simple-09 X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 14:33:23 -0000 Hi Bernard, Thanks for your comments. Please find responses inline. On 09-10-20 04:08 PM, Bernard Aboba wrote: > Review of draft-ietf-dna-simple-09 > > I have reviewed draft-ietf-dna-simple. Overall, I believe this document > still > contains significant technical issues that need to be addressed before > it would be suitable for publication as a Proposed Standard. In particular, > the version of the document sent to IETF last call does not incorporate > fixes > to issues listed in the WG issue tracker as "fixed". This raises the > possibility that > changes from WG last call were not properly applied or even that the wrong > version of the document may have been sent to IETF last call. > > Given the potential problems, a careful check needs to be made of the > changes > between -08 and -09 to make sure that resolutions to WG last call and AD > review comments were properly applied. > > Technical > > Abstract > > This document provides simple procedures for detecting network > attachment in IPv6 hosts, and procedures for routers to support such > services. > > [BA] My understanding was that the goal of Simple DNA was to avoid > changes to routers. Given that, what router procedure need to be > specified? This refers to the optional changes to routers for sending out fast unicast RAs in section 2.4. > > Section 2.4 > > 2.4. DNA Roles > > > Detecting Network Attachment is performed by hosts by sending IPv6 > neighbor discovery and router discovery messages to routers after > connecting to a network. > > It is desirable that routers adopt procedures which allow for fast > unicast Router Advertisement (RA) messages. Routers that follow the > standard neighbor discovery procedure described in [RFC4861] will > delay the router advertisement by a random period between 0 and > MAX_RA_DELAY_TIME (defined to be 500ms) as described in Section 6.2.6 > of [RFC4861]. This delay can be significant and may result in > service disruption. Please note that support for fast unicast RAs is > not necessary since the simple dna procedure can continue to work > using the NS/NA exchange, which will complete earlier than the RA > arrives. > > The host detects that the link-layer may have changed, and then > simultaneously probes the network with Router Solicitations (RSs) and > Neighbor Solicitations (NSs). The host uses advertisements to > determine if the routers it currently has configured are still > available. > > Additionally, on links with no statelessly configured addresses, the > host may make use of DHCPv6 procedures to identify an operable > address. > > [BA] This paragraph does not describe the situations in which > RA delays will be significant. Clarity would be enhanced by > describing this. > > The description of the role of DHCPv6 in this section appears to > conflict with the description in Section 4.6. Section 4.6 discusses > use of Neighbor Discovery probing in parallel with DHCPv6 probing, > implying that RS probing is not used. This section implies that > DHCPv6 probing is only done after a combination of RS and NS > probing does not result in a statelessly configured address. > > Perhaps the best way to explain the interaction is to think of > simple DNA as independent of DHCPv6. That is, implementation > of simple DNA does not change the DHCPv6 state machine or timers; > implementations continue to send the same DHCPv6 packets in the > same situations and with the same timing as they did without > simple DNAv6. The only new wrinkle is the potential for conflicts > between simple DNA and DHCPv6, in which case the information > obtained via DHCPv6 wins. > > This is true regardless of whether an implementation waits for an > RA before deciding whether to use DHCPv6, or whether it sends > DHCPv6 packets regardless of the state of the 'M' and 'O' bits > in the RA. > > My suggested text is as follows: > > 2.4. DNA Overview > > Detecting Network Attachment is performed by hosts after > detecting a link-layer "up" indication. The host simultaneously > sends multicast Router Solicitations (RSs) and unicast Neighbor > Solicitations (NSs) in order to determine whether previously > encountered routers are present on the link. > > Hosts implementing simple DNA may also send DHCPv6 packets, > as described in Section 4.6. Since simple DNA does not > modify the DHCPv6 protocol or state machine, the operation > of DHCPv6 is unchanged. > > Routers that follow the standard neighbor discovery procedure > described in [RFC4861] will delay the router advertisement by a > random period between 0 and MAX_RA_DELAY_TIME (defined to be 500ms) > as described in Section 6.2.6 of [RFC4861]. Hosts implementing > simple DNA can detect the presence of a previously encountered > router using unicast Neighbor Solicitations. As a result, where > the host with a valid configuration is returning to a previously > encountered link, delays in the sending of a Router Advertisement > (RA) will not delay configuration as long as NS probing is > successful. However in situations where the host is > attaching to a link for the first time, or where it does not > have a valid IP address on the link, it will be dependent > on the receipt of an RA for stateless auto-configuration. In > these situations delays in the receipt of an RA can be significant > and may result in service disruption. > > As a result, in addition to implementing simple DNA, it is > desirable that routers adopt procedures which allow for fast > unicast Router Advertisement (RA) messages. Sounds good. Will make this change. > > Section 4.5.1 > > The probing node SHOULD NOT include the Source link-layer address > option in the probe messages. > > [BA] In looking through versions of the document, it appears that this > text > changed between -08 and -09, but it is not clear why. Was this the result > of an editorial error, or was it made in response to the AD review? > My recommendation is that the -08 text be restored: > > The probing node SHOULD include a Source link-layer address option in > the probe messages if the address was obtained using DHCPv6 and the > lease has not expired. Otherwise the probing node SHOULD NOT include > the Source link-layer address option in the probe messages. > > The existing text is problematic since if the SSLAO is not included, > then the ND cache on the router will not be seeded, and return reachability > will not be enabled. This significantly impacts the utility of simple DNA, > which in the v4 version was able to both configuration configuration and > establish bi-directional reachability in a single step. Since the NS is > sent > to a unicast MAC and IP address only when the host has a valid IP address, > I don't think there is a danger of cache pollution. > > Section 4.5.2 > > The probing node SHOULD include a Source link-layer address option in > the probe messages if the address was obtained using DHCPv6 and the > lease has not expired. Otherwise the probing node SHOULD NOT include > the Source link-layer address option in the probe messages. > > [BA] As listed in Issue #15 (listed as fixed in the tracker), > the text was to be changed to indicate that the SLLAO should not be > included in the Router Advertisement: > See > http://webcamserver.eng.monash.edu.au/~warchive/dna/2009-09/msg00003.html > > Although this issue was resolved as fixed, the fix does not appear to have > been applied in the document sent to IETF last call. Was the correct > version > of the document sent to WG last call? I will swap the text regarding SLLAO for 4.5.1 and 4.5.2. Does this work? > > The existing text does not make sense because a single router > solicitation is > sent, not one for each address. Since the router solicitation is sent > once via multicast, it is not clear to me how the advice in this paragraph > can be implemented, since until simple DNA is completed, the host cannot > know > which address (if any) will turn out to be valid. > > Section 4.6 > > Where the host has acquired addresses from DHCPv6 or the host does > not have a global prefix, it MAY prefer to use DHCPv6 probe messages > in parallel with the Neighbor Discovery probing. The DHCPv6 probing > procedures described in this document do not imply any changes to the > DHCPv6 protocol or state machine. > > [BA] The first sentence appears to imply that DHCPv6 probing is done instead > of sending a multicast RS. I don't think this is what was intended. > > Rather, I think what this section is trying to communicate is that > implementation > of simple DNA is largely orthogonal to DHCPv6. If a DHCPv6 > implementation decides > whether to send DHCPv6 packets based on the contents of the RA, then it > will continue > to do that after implementing DNA. If it sends DHCPv6 packets > regardless of the > contents of the RA, then it will continue to do that. Since the timing, > state > machine and contents of DHCPv6 packets is unaffected, simple DNA > continues to > guarantee that it will "do no harm" with respect to performance, > regardless of the > details of the DHCPv6 implementation. > > Here is my recommended rewrite of Section 4.6: > > 4.6. DHCPv6 operation > > Simple DNA does not require a host to implement DHCPv6, nor does it > imply any changes to the DHCPv6 protocol or state machine. > Hosts MAY attempt to obtain IPv6 configuration via DHCPv6 > in parallel with simple DNA probing. This ensures that the > simple DNA procedure will not result in additional delay in > the case where reachability tests fail, or where a DHCPv6 exchange > completes more quickly than the reachability tests. > > In situations where both simple DNA and DHCPv6 are used on the same > link, > it is possible that simple DNA probing will complete successfully, > and then DHCPv6 will complete later with a different result. If this > happens, the procedure described in Section 4.7.1 are utilized. > > Where the host attempts to obtain IPv6 configuration in parallel with > simple DNA, on receiving a link-layer "up" indication, it > sends a DHCPv6 SOLICIT to All_DHCP_Relay_Agents_and_Servers. This > message contains an Identity Association for either a Temporary > Address (IA_TA) or Non-Temporary Address (IA_NA) [RFC3315]. Where an > existing valid address is being tested for operability, this address > should be placed in the Identity Association's IAADDR element, and > the DUID associated with that address should be copied to the DHCP > SOLICIT from the SDAT. > > In order to quickly acquire a new address in the case that link > change has occurred, this SOLICIT message MAY contain the Rapid- > Commit option. > > Where the Rapid-Commit option has not been used, a present DHCP > server will respond with an ADVERTISE message. The IP address > contained in the Identity Association (IA_TA or IA_NA) will contain > an IP Address which is operable for the link. > > Where Rapid-Commit option has been sent, a DHCPv6 server will respond > with REPLY. In addition to being operable, this address is allocated > to the host for the lease duration indicated in the Identity > Association. > > Section 5 > > It probably should be noted that the pseudo code does not include > sending of DHCPv6 packets, since that is orthogonal to simple DNA. OK. Will do > > Appendix A > > Hence agressive retransmissions are mandated. > > [BA] "mandated" -> "necessary". OK. > > o Another issue comes up when the host moves between two networks, > one where manual addressing is being used (say NET1)and the other > where dynamic addressing (DHCPv6) is being used (say NET2). When > the host moves to NET1 from NET2 it tries to confirm both the > manual address and the dynamic address in parallel. If the probe > for the manually assigned address is lost, the DHCPv6 probe will > succeed and the host will incorrectly end up using the DHCPv6 > assigned address (from NET2) on NET1. > > [BA] Since the manual address is only supposed to be used on NET1, this > example is not actually a problem -- it is valid for the host to use > a DHCPv6 assigned address if it moves from NET1 to NET2. The problem > occurs if DHCPv6 is enabled on NET1 and the host ends up using a > DHCPv6 (or stateless autoconfig) address instead of a static one > when it connects to NET1. Suggested change: > > > o Another issue comes up when the host moves between two networks, > one where manual addressing is being used (say NET1)and the other > where dynamic addressing (stateless autoconfig or DHCPv6) is > being used (say NET2). Since the host can obtain a dynamic address > in some situations, it will need to send simple DNA probes and > may also engage in a DHCPv6 exchange. In a situation where the > host moves to NET1 and the NS probes are lost and in addition an > RA is not received, the host will not be able to confirm that it > attached to NET1, and therefore that it should use the manual > configuration for that network. As a result, if DHCPv6 is enabled on > NET1, then the host could mistakenly obtain a dynamic address and > configuration instead of using the manual configuration. To > prevent this problem, simple DNA probing needs to continue even > after the DHCPv6 exchange has completed, and DNA probes need to > take precedence over DHCPv6, contrary to the advice > provided in Section 4.7.1. OK. > > Editorial > > Section 2 > > Hosts require procedures to simply and reliably identify if they have > moved to a different IP network to the one which they have been > recently connected. > > [BA] "to the one which" -> "than the one to which" OK. > > Section 2.1 > > The goal of this document is to specify a simple procedure for > detecting network attachment (Simple DNA) that has the following > characteristics. > > o Routers do not have to be modified to support this scheme. > > o Handle only the simplest and most likely use cases. > > o Work at least as quickly as standard neighbor discovery. > > > [BA] The second and third bullets do not have a parallel grammatical > structure. How about this? > > The goal of this document is to specify a simple procedure for > detecting network attachment (Simple DNA) that has the following > characteristics: > > o Routers do not have to be modified to support this scheme; > > o The most common use cases are optimized; > > o In the worst case, detection latency is equal to that of > existing schemes so that performance is never degraded; Sounds good. > > > Section 4.7.1 > > It is possible that the DHCPv6 based probes and the neighbor > discovery based probes complete with conflicting results. In this > case, the host SHOULD use the following rules to determine the final > result. > > o If the DHCPv6 exchange was authenticated, use the result from the > DHCPv6 probe. > > o If the DHCPv6 exchange was not authenticated and the neighbor > discovery exchange was protected by SEND [RFC3971], use the result > from the neighbor discovery probe. > > o If both the DHCPv6 and neighbor discovery exchanges were not > authenticated, use the result from the DHCPv6 probe > > [BA] The use of the term "DHCPv6 probe" is a bit confusing in that it seems > to imply that DHCPv6 operates differently with simple DNA. My > recommendation > is to eliminate use of this term, as follows: > > It is possible that DHCPv6 exchanges and the neighbor > discovery based probes complete with conflicting results. In this > case, the host SHOULD use the following rules to determine the final > result: > > o If the DHCPv6 exchange was authenticated, use the result from > DHCPv6. > > o If the DHCPv6 exchange was not authenticated and the neighbor > discovery exchange was protected by SEND [RFC3971], use the result > from the neighbor discovery probe. > > o If both the DHCPv6 and neighbor discovery exchanges were not > authenticated, use the result from DHCPv6. OK. > > Section 4.9 > > The first paragraph isn't about retransmission, so it might be better to > move it to section 4.7.1. OK. Thanks Suresh From bernard_aboba@hotmail.com Wed Oct 21 07:43:20 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E00BE3A67F0; Wed, 21 Oct 2009 07:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.204 X-Spam-Level: X-Spam-Status: No, score=0.204 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQtLrioVqBe0; Wed, 21 Oct 2009 07:43:19 -0700 (PDT) Received: from blu0-omc3-s32.blu0.hotmail.com (blu0-omc3-s32.blu0.hotmail.com [65.55.116.107]) by core3.amsl.com (Postfix) with ESMTP id DB4683A6819; Wed, 21 Oct 2009 07:43:14 -0700 (PDT) Received: from BLU137-DS1 ([65.55.116.73]) by blu0-omc3-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 07:43:22 -0700 X-Originating-IP: [131.107.0.71] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Suresh Krishnan'" References: <4ADF1B9F.5060607@ericsson.com> In-Reply-To: <4ADF1B9F.5060607@ericsson.com> Date: Wed, 21 Oct 2009 07:43:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpSW3TirLSi6Dl0Q46LunF9C4JrMgAASAEg Content-Language: en-us X-OriginalArrivalTime: 21 Oct 2009 14:43:23.0031 (UTC) FILETIME=[D6F4B270:01CA525C] Cc: dna@ietf.org, ops-dir@ietf.org, ietf@ietf.org Subject: Re: [dna] Review of draft-ietf-dna-simple-09 X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 14:43:21 -0000 Suresh said: "I will swap the text regarding SLLAO for 4.5.1 and 4.5.2. Does this work?" Yes. I think the changes got swapped, somehow. From gdaley@netstarnetworks.com Tue Oct 20 15:44:23 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADA2F3A6944 for ; Tue, 20 Oct 2009 15:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNkorcPPenTD for ; Tue, 20 Oct 2009 15:44:23 -0700 (PDT) Received: from mail.syd.netstarnetworks.com (mail.syd.netstarnetworks.com [203.8.7.220]) by core3.amsl.com (Postfix) with ESMTP id B5B503A68D6 for ; Tue, 20 Oct 2009 15:44:22 -0700 (PDT) Received: from sdcmail.netstarnetworks.com ([10.18.193.12]) by mail.syd.netstarnetworks.com (8.12.8/8.12.8) with ESMTP id n9KMiFRs032133; Wed, 21 Oct 2009 08:44:18 +1000 Received: from melmail.netstarnetworks.com ([10.20.193.13]) by sdcmail.netstarnetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 09:43:26 +1100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Oct 2009 09:43:25 +1100 Message-ID: <6983BF97BFC24D4EA551F14071232918012C7532@melmail.netstarnetworks.com> In-Reply-To: <25154_1256073124_4ADE27A4_25154_3045246_1_4ADE274E.3090700@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [DNA] DNA working group completion Thread-Index: AcpRygprM9LVbRp+QCmtVfh+DJId1wAC1X9A References: <25156_1255687743_4AD8463E_25156_5479872_1_4AD84605.8050903@piuha.net> <2972_1255728734_4AD8E65E_2972_3663297_1_4AD8E5C6.4070603@ericsson.com> <25144_1255730168_4AD8EBF8_25144_89518_1_4AD8EBD9.7060008@piuha.net> <4AD8F239.3090006@ericsson.com> <25154_1256073124_4ADE27A4_25154_3045246_1_4ADE274E.3090700@piuha.net> From: "Greg Daley" To: "Jari Arkko" , "Suresh Krishnan" X-OriginalArrivalTime: 20 Oct 2009 22:43:26.0654 (UTC) FILETIME=[BCD705E0:01CA51D6] X-Mailman-Approved-At: Wed, 21 Oct 2009 08:02:28 -0700 Cc: DNA , dna@ietf.org Subject: Re: [dna] [DNA] DNA working group completion X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 22:44:23 -0000 Hi Jari,=20 I'm happy to proceed with the tentative draft as individual submission, but wonder if the draft-ietf-dna-tentative would have to drop the "draft-ietf". I haven't heard from the other authors, and we would have to ensure it is OK with them. Greg Daley Security Consultant NetStar Australia Pty Ltd E-mail: gdaley@netstarnetworks.com Mobile: +61 401 772 770 Direct: +61 3 8532 4042 Fax: +61 3 8532 4032=20 > -----Original Message----- > From: owner-dna@ecselists.eng.monash.edu.au=20 > [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of Jari Arkko > Sent: Wednesday, 21 October 2009 8:11 AM > To: Suresh Krishnan > Cc: DNA; dna@ietf.org > Subject: Re: [DNA] DNA working group completion >=20 >=20 > > Makes sense. I will talk to the authors to see how comfortable they=20 > > feel about the documents. >=20 > Was there a response from the authors? (And they could speak=20 > here on the=20 > list, too, I suppose...) >=20 > Jari >=20 >=20 From jari.arkko@piuha.net Fri Oct 23 03:46:53 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A0913A6867 for ; Fri, 23 Oct 2009 03:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMH3BKg9runG for ; Fri, 23 Oct 2009 03:46:52 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 525883A682D for ; Fri, 23 Oct 2009 03:46:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 679B6D4949; Fri, 23 Oct 2009 13:47:02 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKy0rFFfKFXp; Fri, 23 Oct 2009 13:47:01 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id DEBE2D4904; Fri, 23 Oct 2009 13:47:01 +0300 (EEST) Message-ID: <4AE189A5.5040304@piuha.net> Date: Fri, 23 Oct 2009 13:47:01 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: DNA References: <25156_1255687743_4AD8463E_25156_5479872_1_4AD84605.8050903@piuha.net> <2972_1255728734_4AD8E65E_2972_3663297_1_4AD8E5C6.4070603@ericsson.com> <25144_1255730168_4AD8EBF8_25144_89518_1_4AD8EBD9.7060008@piuha.net> <4AD8F239.3090006@ericsson.com> <25154_1256073124_4ADE27A4_25154_3045246_1_4ADE274E.3090700@piuha.net> <6983BF97BFC24D4EA551F14071232918012C7532@melmail.netstarnetworks.com> In-Reply-To: <6983BF97BFC24D4EA551F14071232918012C7532@melmail.netstarnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dna@ietf.org Subject: Re: [dna] [DNA] DNA working group completion X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 10:46:53 -0000 I have done a preliminary review of the two proposed additional documents. My conclusion is that the documents can be published, but both require some amount of revision. I will send more specific comments to the authors and to the list soon. I do not want to hold up the closing of the working group while waiting for revising these documents, however. I have asked the secretariat to send a working group termination announcement and want to thank everyone for a successful end of the work. There will be some discussion (as you have seen) on the dna-simple document as it progresses through IETF Last Call and the IESG. And I hope to get new versions of the dna-tentative and dna-protocol documents as soon as possible -- by Monday's deadline if you can manage it :-) I will take them forward as AD sponsored submissions. Jari From jari.arkko@piuha.net Fri Oct 23 03:47:38 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A7FE3A682D for ; Fri, 23 Oct 2009 03:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 FEDN62hQoKqX for ; Fri, 23 Oct 2009 03:47:37 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id AE74F3A6828 for ; Fri, 23 Oct 2009 03:47:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id F15B4D4949; Fri, 23 Oct 2009 13:47:46 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfXbRIa-H3es; Fri, 23 Oct 2009 13:47:45 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id CA57AD4904; Fri, 23 Oct 2009 13:47:45 +0300 (EEST) Message-ID: <4AE189D1.2080907@piuha.net> Date: Fri, 23 Oct 2009 13:47:45 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: draft-ietf-dna-tentative@tools.ietf.org, Greg Daley Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DNA , "dna@ietf.org" Subject: [dna] comments on draft-ietf-dna-tentative X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 10:47:38 -0000 Here are a few comments on this draft. Overall, this document is in reasonable shape, but contained a number of small errors. Detailed comments: First, which status would this document be published with? Historic/Informational as in the case of draft-ietf-dna-protocol? Or something else? Second, the document needs to be re-submitted to the directories before I can enter it to the tracker. > In a case where it is safe to send a Source Link-Layer Address > Option, a host SHOULD NOT send a TO, since the message may be > misinterpreted by legacy nodes. > > Importantly, a node MUST NOT send a Tentative Option in the same > message where a Source Link-Layer Address Option is sent > Any Router Solicitation from a Preferred, Deprecated or Optimistic > address MAY be sent with a Tentative Option [RFC4429 ]. > Aren't these two text excerpts in conflict with each other? RS typically includes a SLLA, so normally we would not be able to use a TO based on the rule in the earlier text. Also, if the source address is Preferred or Deprecated, an SLLA can be used and per the earlier rule, should not be used. > An extension which allows Router Solicitations to be sent with a TO > from the unspecified address is described in Appendix C . > I understood from Greg that this has not been implemented. Does it make sense to remove it from the draft as well? > For standardization, this document requires that the IANA allocate > the Tentative Option for link-layer addressing (Section Section 2.1 ) > from the IPv6 Neighbour Discovery options for IPv6. > This document asks the IANA to allocate ... > Previous (older) experimental implementations have used the value > 0x11 (17) for the Tentative Option, before the IPv6 Neighbour > Discovery experimental range was defined [RFC4727 ]. > This value does not appear to be free anymore, according to http://www.iana.org/assignments/icmpv6-parameters I would suggest deleting this paragraph. > The use of the Tentative Option in Neighbour and Router Solicitation > messages acts in a similar manner to SLLAO, updating neighbour cache > entries, in a way which causes packet transmission. > ? Did you mean "affects the transmission of subsequent packets"? > Particular care should be taken that transmission of messages > complies with existing IPv6 Neighbour Discovery Procedures, so that > unmodified hosts do not receive invalid messages. > I'm not sure what you are asking for here. Missing things: the document should clearly state somewhere how you deal with legacy nodes that do not implement this RFC. My understanding is that since unknown options are ignored, the resulting behaviour is equivalent to sending an ND message without SLLAO (which is the current behaviour with standard ND anyway). Correct? Jari From gdaley@netstarnetworks.com Sun Oct 25 09:38:55 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D53D3A67A8 for ; Sun, 25 Oct 2009 09:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-J2D6DwbvL3 for ; Sun, 25 Oct 2009 09:38:53 -0700 (PDT) Received: from mail.syd.netstarnetworks.com (mail.syd.netstarnetworks.com [203.8.7.220]) by core3.amsl.com (Postfix) with ESMTP id D07133A68B7 for ; Sun, 25 Oct 2009 09:38:52 -0700 (PDT) Received: from sdcmail.netstarnetworks.com ([10.18.193.12]) by mail.syd.netstarnetworks.com (8.12.8/8.12.8) with ESMTP id n9PGd5R5024200; Mon, 26 Oct 2009 03:39:06 +1100 Received: from melmail.netstarnetworks.com ([10.20.193.13]) by sdcmail.netstarnetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 03:38:47 +1100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5591.9F391238" Date: Mon, 26 Oct 2009 03:38:46 +1100 Message-ID: <6983BF97BFC24D4EA551F140712329181FA7CD@melmail.netstarnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on draft-ietf-dna-tentative Thread-Index: AcpTzkgMjMGGNX80ShOtJZ0v/j5OlQBv5a/X References: <4AE189D1.2080907@piuha.net> From: "Greg Daley" To: "Jari Arkko" , X-OriginalArrivalTime: 25 Oct 2009 16:38:47.0777 (UTC) FILETIME=[A0141510:01CA5591] X-Mailman-Approved-At: Mon, 26 Oct 2009 08:24:41 -0700 Cc: DNA , dna@ietf.org Subject: Re: [dna] comments on draft-ietf-dna-tentative X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 16:38:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5591.9F391238 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jari,=20 Thanks for the feedback. > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Fri 10/23/2009 9:47 PM > To: draft-ietf-dna-tentative@tools.ietf.org; Greg Daley > Cc: dna@ietf.org; DNA > Subject: comments on draft-ietf-dna-tentative =20 > Here are a few comments on this draft. Overall, this document is in=20 > reasonable shape, but contained a number of small errors. > > Detailed comments: > > First, which status would this document be published with?=20 > Historic/Informational as in the case of draft-ietf-dna-protocol? Or=20 > something else? > I think either Informational, (or Experimental) but not Historic. Standards track would have been nice, but a standard would need more = interest, no? > Second, the document needs to be re-submitted to the directories = before=20 > I can enter it to the tracker. The new draft is available at: http://www.ietf.org/id/draft-ietf-dna-tentative-03.txt > > In a case where it is safe to send a Source Link-Layer Address > > Option, a host SHOULD NOT send a TO, since the message may be > > misinterpreted by legacy nodes. > > > > Importantly, a node MUST NOT send a Tentative Option in the same > > message where a Source Link-Layer Address Option is sent > > Any Router Solicitation from a Preferred, Deprecated or Optimistic > > address MAY be sent with a Tentative Option [RFC4429 = ]. > =20 > Aren't these two text excerpts in conflict with each other? RS = typically=20 > includes a SLLA, so normally we would not be able to use a TO based on = > the rule in the earlier text. Also, if the source address is Preferred = > or Deprecated, an SLLA can be used and per the earlier rule, should = not=20 > be used. RS requirements are currently a SHOULD, but RFC4429 allows use of RS = with unicast source while Optimistic, so long as SLLAO is not included (it would = pollute the NCE and not be discovered or overridden by an existing address owner). (as an aside, Preferred and Deprecated addresses are still valid for ND, = though. There's no change in behaviour between these two states in sending solicitations. These are = not the focus: What is interesting is initial link attachment and sending solicitations = in the first milliseconds after attachment. That initial query gains most from Optimistic state). I have reorganized and augmented the text as follows: - In a case where it is safe to send a Source Link-Layer Address - Option, a host SHOULD NOT send a TO, since the message may be - misinterpreted by legacy nodes. - - Importantly, a node MUST NOT send a Tentative Option in the same - message where a Source Link-Layer Address Option is sent. + In a case where it is safe to send a Source Link-Layer Address + Option, a host SHOULD NOT send a TO, since the message may be + misinterpreted by legacy nodes. Importantly, a node MUST NOT send a + Tentative Option in the same message where a Source Link-Layer + Address Option is sent. + + Particularly, Tentative Options are premitted to be sent when + addressing state precludes sending the SLLAO, but a neighbour cache + entry will be created on a peer node [RFC4429]. Please note the (typo) premitted. I will update along with any feedback = if I get the chance today. > > An extension which allows Router Solicitations to be sent with a TO > > from the unspecified address is described in Appendix C = . > > =20 > I understood from Greg that this has not been implemented. Does it = make=20 > sense to remove it from the draft as well? I have removed references to this section. > > For standardization, this document requires that the IANA allocate > > the Tentative Option for link-layer addressing (Section Section 2.1 = ) > > from the IPv6 Neighbour Discovery options for IPv6. > > =20 > This document asks the IANA to allocate ... Thanks. Done. > > Previous (older) experimental implementations have used the value > > 0x11 (17) for the Tentative Option, before the IPv6 Neighbour > > Discovery experimental range was defined [RFC4727 = ]. > > =20 > This value does not appear to be free anymore, according to=20 > http://www.iana.org/assignments/icmpv6-parameters > > I would suggest deleting this paragraph. Thanks. Done. > > The use of the Tentative Option in Neighbour and Router Solicitation > > messages acts in a similar manner to SLLAO, updating neighbour cache > > entries, in a way which causes packet transmission. > =20 > ? > Did you mean "affects the transmission of subsequent packets"? Thanks for that. The re-read stymied me too. > > Particular care should be taken that transmission of messages > > complies with existing IPv6 Neighbour Discovery Procedures, so that > > unmodified hosts do not receive invalid messages. > > =20 > I'm not sure what you are asking for here. I'm not sure if there was a behaviour being alluded to which is no = longer in the document. As a quick stab (it is 3:30 and my daughter is awake by 5...) I have amended it to "Particular care is taken..." I will think on it and resubmit by deadline if able. > Missing things: the document should clearly state somewhere how you = deal=20 > with legacy nodes that do not implement this RFC. My understanding is=20 > that since unknown options are ignored, the resulting behaviour is=20 > equivalent to sending an ND message without SLLAO (which is the = current=20 > behaviour with standard ND anyway). Correct? > > Jari. You are correct about the legacy behaviour. =20 There is an appendix showing the behaviour of the devices upon = reception, which is largely one of: a) Transmit to an existing valid NCE b) NS to the original sender to create an NCE for the RA or NA response c) Multicast response (where appropriate). I have added the following paragraph to the end of the Introduction: + Operations in this document are safe with respect to existing nodes + that implement IPv6 Neighbor Discovery [RFC4861] and Stateless + Address Autoconfiguration. Expected behaviours of legacy decives = are + summarized in Appendix B. Alas, another typo (decives). =20 Sorry about the response's crudeness. I saw your e-mail and wished to = get a submission in which implemented some of the points you made. Sincerely, Greg ------_=_NextPart_001_01CA5591.9F391238 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: comments on draft-ietf-dna-tentative

Hi Jari,

Thanks for the feedback.

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net]
= > Sent: Fri 10/23/2009 9:47 PM
> To: draft-ietf-dna-tentative@tools.ietf.org; Greg Daley
> Cc: dna@ietf.org; DNA
> Subject: comments on draft-ietf-dna-tentative

> Here are a few comments on this draft. Overall, this document is = in
> reasonable shape, but contained a number of small errors.
>
> Detailed comments:
>
> First, which status would this document be published with?
> Historic/Informational as in the case of draft-ietf-dna-protocol? = Or
> something else?
>

I think either Informational, (or Experimental) but not Historic.
Standards track would have been nice, but a standard would need more = interest, no?

> Second, the document needs to be re-submitted to the directories = before
> I can enter it to the tracker.

The new draft is available at:

http://ww= w.ietf.org/id/draft-ietf-dna-tentative-03.txt

> > In a case where it is safe to send a Source Link-Layer = Address
> > Option, a host SHOULD NOT send a TO, since the message may = be
> > misinterpreted by legacy nodes.
> >
> > Importantly, a node MUST NOT send a Tentative Option in the = same
> > message where a Source Link-Layer Address Option is sent
> > Any Router Solicitation from a Preferred, Deprecated or = Optimistic
> > address MAY be sent with a Tentative Option [RFC4429 <http://tools.ietf.org/html/rf= c4429>].
>  

> Aren't these two text excerpts in conflict with each other? RS = typically
> includes a SLLA, so normally we would not be able to use a TO based = on
> the rule in the earlier text. Also, if the source address is = Preferred
> or Deprecated, an SLLA can be used and per the earlier rule, should = not
> be used.

RS requirements are currently a SHOULD, but RFC4429 allows use of RS = with unicast
source while Optimistic, so long as SLLAO is not included (it would = pollute the NCE
and not be discovered or overridden by an existing address owner).

(as an aside, Preferred and Deprecated addresses are still valid for ND, = though.  There's no change in
behaviour between these two states in sending solicitations.  These = are not the focus:
What is interesting is initial link attachment and sending solicitations = in the first milliseconds after
attachment.  That initial query gains most from Optimistic = state).


I have reorganized and augmented the text as follows:

-   In a case where it is safe to send a Source Link-Layer = Address
-   Option, a host SHOULD NOT send a TO, since the message may = be
-   misinterpreted by legacy nodes.
-
-   Importantly, a node MUST NOT send a Tentative Option in = the same
-   message where a Source Link-Layer Address Option is = sent.


+   In a case where it is safe to send a Source Link-Layer = Address
+   Option, a host SHOULD NOT send a TO, since the message may = be
+   misinterpreted by legacy nodes.  Importantly, a node = MUST NOT send a
+   Tentative Option in the same message where a Source = Link-Layer
+   Address Option is sent.
+
+   Particularly, Tentative Options are premitted to be sent = when
+   addressing state precludes sending the SLLAO, but a = neighbour cache
+   entry will be created on a peer node [RFC4429].

Please note the (typo) premitted.  I will update along with any = feedback
if I get the chance today.


> > An extension which allows Router Solicitations to be sent with = a TO
> > from the unspecified address is described in Appendix C <http://tools.ietf.org/html/draft-ietf-dna-tentative-02#appendix-C&g= t;.
> >  

> I understood from Greg that this has not been implemented. Does it = make
> sense to remove it from the draft as well?

I have removed references to this section.



> > For standardization, this document requires that the IANA = allocate
> > the Tentative Option for link-layer addressing (Section = Section 2.1 <http://tools.ietf.org/html/draft-ietf-dna-tentative-02#section-2.1= >)
> > from the IPv6 Neighbour Discovery options for IPv6.
> >  
> This document asks the IANA to allocate ...

Thanks. Done.

> > Previous (older) experimental implementations have used the = value
> > 0x11 (17) for the Tentative Option, before the IPv6 = Neighbour
> > Discovery experimental range was defined [RFC4727 <http://tools.ietf.org/html/rf= c4727>].
> >  
> This value does not appear to be free anymore, according to
> http://www.ian= a.org/assignments/icmpv6-parameters
>
> I would suggest deleting this paragraph.

Thanks. Done.

> > The use of the Tentative Option in Neighbour and Router = Solicitation
> > messages acts in a similar manner to SLLAO, updating neighbour = cache
> > entries, in a way which causes packet transmission.
>  
> ?

> Did you mean "affects the transmission of subsequent = packets"?

Thanks for that.  The re-read stymied me too.

> > Particular care should be taken that transmission of = messages
> > complies with existing IPv6 Neighbour Discovery Procedures, so = that
> > unmodified hosts do not receive invalid messages.
> >  
> I'm not sure what you are asking for here.

I'm not sure if there was a behaviour being alluded to which is no = longer
in the document.

As a quick stab (it is 3:30 and my daughter is awake by 5...) I have
amended it to "Particular care is taken..."

I will think on it and resubmit by deadline if able.

> Missing things: the document should clearly state somewhere how you = deal
> with legacy nodes that do not implement this RFC. My understanding = is
> that since unknown options are ignored, the resulting behaviour = is
> equivalent to sending an ND message without SLLAO (which is the = current
> behaviour with standard ND anyway). Correct?
>
> Jari.

You are correct about the legacy behaviour. 

There is an appendix showing the behaviour of the devices upon = reception,
which is largely one of:
a) Transmit to an existing valid NCE
b) NS to the original sender to create an NCE for the RA or NA = response
c) Multicast response (where appropriate).


I have added the following paragraph to the end of the Introduction:

+   Operations in this document are safe with respect to = existing nodes
+   that implement IPv6 Neighbor Discovery [RFC4861] and = Stateless
+   Address Autoconfiguration.  Expected behaviours of = legacy decives are
+   summarized in Appendix B.

Alas, another typo (decives). 


Sorry about the response's crudeness.  I saw your e-mail and wished = to get
a submission in which implemented some of the points you made.


Sincerely,
Greg

------_=_NextPart_001_01CA5591.9F391238-- From jari.arkko@piuha.net Thu Oct 29 14:58:07 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 624A428C0D6 for ; Thu, 29 Oct 2009 14:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.009, 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 vyZnsrgQx8vp for ; Thu, 29 Oct 2009 14:58:06 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 7B14D3A6800 for ; Thu, 29 Oct 2009 14:58:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 6945FD4927; Thu, 29 Oct 2009 23:57:37 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GE5ZhNiy0vpY; Thu, 29 Oct 2009 23:57:36 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 2D4C6D491F; Thu, 29 Oct 2009 23:57:35 +0200 (EET) Message-ID: <4AEA0FCE.4000704@piuha.net> Date: Thu, 29 Oct 2009 23:57:34 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Sathya Narayanan References: <4ADE2B90.6060900@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DNA , "dna@ietf.org" Subject: [dna] Comments on draft-ietf-dna-protocol X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 21:58:07 -0000 Sathya, Here are a few comments on draft-ietf-dna-protocol. Overall, this is a complex scheme and having read this again after a long break, I'm now even more glad that we got the dna-simple document moving forward. However, I think we should publish even dna-protocol as an RFC. It is an interesting design worth a permanent record. I do have a long list of comments, though, and I hope you can publish a new draft version so that the document can be taken forward. I'm thinking of Historical or Experimental as the proper designation for the document. Detailed comments: The document needs to be resubmitted as it is currently expired. > Design document for Detecting Network Attachment in IPv6 Networks (DNAv6 > Design) > Might be better as "Design Alternative for Detecting ..." Abstract is too long. Maybe you should just keep this part: In this memo, a mechanism that was developed for detection of network attachment is documented for future reference. This memo is an informational document and thus does not define a new standard. The mechanism proposed in this informational RFC requires the hosts to monitor all the prefixes advertised on the link and use it for link identification in the presence of non-DNAv6 routers is presented. A more efficient link- identification mechanism requiring the DNAv6 routers to monitor the link for advertised prefixes to assist the hosts in link identification combined with a fast router advertisement mechanism that selects the order of response for the router deterministically is also presented. Run spell on the document. > This memo also defines a mechanism to exchange Source Link-Layer Address without affecting the neighbor caches when the host is performing Optimistic DAD. > Wasn't this already in draft-ietf-dna-tentative? > Even though this > document recommends the use of a prefix as the representative of the > link, future specifications can use the Learned Prefix Option to > include a non-prefix identifier as long as this identifier is 128 bit > long to avoid collision with any currently assigned prefix. So, any > future non-prefix link identifier MUST be 128 bits long. > > 5.1.6.3.1 Using non-prefix identifier as common prefix I felt that this extensibility confused the document a little bit. Could this be removed? > DNAv6 avoids this delay by using a different mechanism to ensure that > two routers will not respond at exactly the same time while allowing > one of the routers on the link to respond immediately. > The results of that function are then compared to create > a ranking, and the ranking determines the delay each router will use > when responding to the RS. The router which is ranked as #0 will > respond with a zero delay. > Do I understand correctly that there will still be several responses to a single RS? Perhaps this should be highlighted. Note that that your scheme does not provide the same overall limit on the number of RAs appearing on the link as the rate limit defined in RFC 4861. > 4.1 New Flags > > This document defines two new flags to be exchanged between the > router and hosts. I'd like to see these flags in the extension option defined in RFC 5075, not directly in the RA header. > the following information MUST be stored: > > 1. Link-local source address of advertising router > > 2. Token equal to the first 64 bits of an SHA-1 hash of the above address > It seems a bit silly to have a MUST requirement to store X and f(X)... > Each router MUST include itself in the DNARouterList and generate a > token for itself as described above based on the link-local address > used in its RA messages. > As above. > an abbreviated Router Advertisement.This abbreviated advertisement Missing space > A CompleteRA is formed as follows: Missing space > Note that this smallest prefix > is the smallest of all the prefixes configured on the routers on the > link and may not be the smallest prefix used in the link through > stateful address configuration. > Although, at least currently, prefixes used even for stateful address autoconfiguration come from RAs. > When a router receives a new prefix in PIO, if the prefix is smaller > than the current common prefix and has valid lifetime greater than > LEAST_VALID_LIFETIME, the router selects that new prefix as a new > common prefix. But it is also possible that the new smallest prefix comes through configuration in THIS router. In that case it is not the reception of the PIO that triggers this selection. > Whenever a router sends an RA, whether solicited or unsolicited, it > MUST include the common prefix in it. Hence, all RAs MUST carry the > common prefix except the abbreviated RA message sent in response to a > RS with LO. I guess I am missing the point of having BOTH the landmark AND the common prefix. Is there some difference in use that prevents just selecting one, and sticking to that? And if the RAs responding to LO can skip the common prefix, why is it so important to include the common prefix in other RAs? Important enough that a MUST is needed? Or, if the MUST is really needed, is there something that breaks when use just the landmark option? > Sinice information from the Learned Prefix Option is only stored in typo > IF (Receive RA is a CompleteRA) THEN > > { > > /* We already checked if there are any matching prefix before. > Since this is a CompleteRA, implies link-change.*/ > > Link change has occured. > > RETURN; // Don't have to do the following checks. > > } > > { > > Link change has occured. > > RETURN; // Don't have to do the following checks. > > } --> > > IF (DNAHostPrefixList is marked as complete (i.e. the completeness > criteria is already met)) THEN > The code seems broken. Is there an IF missing around the braces above? There seems to be a RETURN followed by some further code, which does not make sense. > Wait for NUM_RS_RA_COMPLETE exchanges of RS/RA message to be done > since the previous link UP event (Previous link UP event here refers > to the link UP received before the current link UP event that lead to > this processing). > > IF (One of the received RA contains a prefix matching a prefix in > DNAHostPrefixList from before the current link UP event), THEN No > link change has occured ELSE link change has occured. > Pseudo-code style changed here. Please use the same style, braces etc. > Note that this procedure does not prevent a MN from sending packets s/MN/host/ Missing things: I did not see a discussion of how prefixes or routers get removed from the host or router data structures. > received RAs as in Section 5.5.3 of RFC 2461 [3]. That is, if an RA It seems weird that you refer to the old 2461 here. Also, is the procedure presented in Section 5.2.7.3 according to the current understanding of the M&O bits? > 6.3 Tentative options If you refer to draft-ietf-dna-tentative, do you need this section? > SEND says that DAD defenses MAY be accepted even from non SEND nodes ... according to the SEND specification (RFC 3971 Section N.N) DAD defenses ... > SEND says that DAD defenses MAY be accepted even from non SEND nodes > for the first configured address [4]. > > While deconfiguring the address is a valid action in the case where a > host collides with another address owner after arrival on a new link, > In the case that the host returns immediately to the same link, such > a DAD defense NA message may be a denial-of-service attempt. > It seems that there are two separate cases. I believe 3971 & 3972 still hold: whenever you create a new address, you should not accept collisions beyond a certain collision count. However, IF you have confirmed that you re-attached to the same link... I would not run DAD. > 10. Informative References You need to split references to normative and informative. > [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery > for IP Version 6 (IPv6)", RFC 2461, December 1998. > Refer to the new one instead. Jari