Re: [dna] next steps on draft-ietf-dna-simple

Jari Arkko <jari.arkko@piuha.net> Fri, 11 December 2009 07:51 UTC

Return-Path: <jari.arkko@piuha.net>
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 703403A683F; Thu, 10 Dec 2009 23:51:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level:
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 G+CsKF8xyx10; Thu, 10 Dec 2009 23:51:18 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 0024E3A67D1; Thu, 10 Dec 2009 23:51:18 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 02B9CD498B; Fri, 11 Dec 2009 09:51:06 +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 bLTIRH06eMyt; Fri, 11 Dec 2009 09:51:05 +0200 (EET)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 1F390D4930; Fri, 11 Dec 2009 09:51:05 +0200 (EET)
Message-ID: <4B21F9E8.9060009@piuha.net>
Date: Fri, 11 Dec 2009 09:51:04 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Suresh Krishnan <suresh.krishnan@ericsson.com>
References: <4B0655CB.2040309@piuha.net> <4B203D25.5090409@ericsson.com>
In-Reply-To: <4B203D25.5090409@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: DNA <dna@eng.monash.edu.au>, "dna@ietf.org" <dna@ietf.org>, IESG <iesg@ietf.org>, "draft-ietf-dna-simple@tools.ietf.org" <draft-ietf-dna-simple@tools.ietf.org>
Subject: Re: [dna] next steps on draft-ietf-dna-simple
X-BeenThere: dna@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNA working group mailing list <dna.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dna>, <mailto:dna-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dna>
List-Post: <mailto:dna@ietf.org>
List-Help: <mailto:dna-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dna>, <mailto:dna-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Dec 2009 07:51:19 -0000

Your plans sound good, Suresh. Thanks.

Jari

Suresh Krishnan wrote:
> Hi Jari,
>   Thank you for setting a good way forward with this document and 
> sorry for the delayed response. Please see my responses inline.
>
> On 09-11-20 03:39 AM, Jari Arkko wrote:
>> The IESG reviewed this draft in our meeting yesterday. A number of 
>> issues were brought up, most of it already resolved but some still 
>> remain. Here are the changes that I've entered as RFC Editor notes:
>>
>> 1) Updates 4861 issue per Brian Carpenter's review comments:
>>
>>   Please remove the "Updates 4861" claim from the header.
>
> OK. Since a new rev is needed anyway, I will update the draft itself 
> so that the RFC Ed note is not required.
>
>>
>> 2) Unclear specification with respect to what the draft requires 
>> about fast RAs. I believe the current wording referred to 
>> draft-ietf-dna-frd. Some readers thought our specification was 
>> requiring a change from the 4861 rules that dictate a delay before 
>> the RS can go out.
>>
>>   Please remove the following text from Section 2.4:
>>
>>   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.
>
> Will do.
>
>>
>> 3) An additional security consideration issue was brought in secdir 
>> review.
>>
>>   Please add the following text to the end of the security
>>   considerations section:
>>
>>   The DNA procedure does not in itself provide positive, secure   
>> authentication of the router(s) on the network, or authentication of
>>   the network itself, as e.g. would be provided by mutual authentication
>>   at the link layer. Therefore when such assurance is not available, the
>>   host MUST NOT make any security-sensitive decisions based on the DNA
>>   procedure. In particular, it MUST NOT decide it has rejoined a network
>>   known to be physically secure, and proceed to abandon cryptographic
>>   protection.
>
> Will add this text.
>
>>
>> 4) Lars Eggert was happy that the draft included retransmission 
>> rules, but noted that the draft should also set an upper limit on how 
>> many previous routers are probed.
>>
>>   Please add the following text to end of Section 4.4:
>>
>>   A Simple DNA implementation SHOULD limit probing to at most
>>   six previously seen routers.
>>
>> Everyone happy with these changes? Also, we have a few remaining issues:
>
> Will do.
>
>>
>> 5) Lars asked whether some of the SHOULDs in the document should 
>> really be MUSTs. In my review this is not universally true at least. 
>> For instance, you may give some freedom for implementations to avoid 
>> sending probes if there are too many link up events in a short time 
>> period. However, we'd like you Suresh go through the document and for 
>> each SHOULD think about what the right keyword is. Sometimes it might 
>> be a MUST, sometimes a SHOULD. In some of the cases where its a 
>> SHOULD, it might be good to include a sentence or two about what 
>> issues might be considered when implementing it.
>
> I have identified a bunch of SHOULDs that need to be changed to MUSTs. 
> I will try to add explanatory text to the other SHOULDs.
>
>>
>> 6) We need to respond to Ralph Droms' detailed review. (Thank you 
>> Ralph!) I think we can forget the Updates 4861 part of his discuss, 
>> but the rest is relevant. I'm including his Discuss here for 
>> completeness sake:
>
> I will go over the document and change/remove any text that insinuates 
> that simple dna changes either DHCPv6 or RFC4861 procedures in any 
> way. That should resolve most of the concerns Ralph has raised in this 
> review.
>
> Thanks
> Suresh
>
>