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

Jari Arkko <> Fri, 11 December 2009 07:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 703403A683F; Thu, 10 Dec 2009 23:51:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G+CsKF8xyx10; Thu, 10 Dec 2009 23:51:18 -0800 (PST)
Received: from ( [IPv6:2001:14b8:400::130]) by (Postfix) with ESMTP id 0024E3A67D1; Thu, 10 Dec 2009 23:51:18 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 02B9CD498B; Fri, 11 Dec 2009 09:51:06 +0200 (EET)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (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 (Postfix) with ESMTP id 1F390D4930; Fri, 11 Dec 2009 09:51:05 +0200 (EET)
Message-ID: <>
Date: Fri, 11 Dec 2009 09:51:04 +0200
From: Jari Arkko <>
User-Agent: Thunderbird (X11/20090817)
MIME-Version: 1.0
To: Suresh Krishnan <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: DNA <>, "" <>, IESG <>, "" <>
Subject: Re: [dna] next steps on draft-ietf-dna-simple
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, 11 Dec 2009 07:51:19 -0000

Your plans sound good, Suresh. Thanks.


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