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

Suresh Krishnan <> Thu, 10 December 2009 00:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6EAA33A68DD; Wed, 9 Dec 2009 16:15:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9-ZKhCsZ3WiO; Wed, 9 Dec 2009 16:15:06 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7CF9F3A684F; Wed, 9 Dec 2009 16:15:06 -0800 (PST)
Received: from ([]) by (8.13.1/8.13.1) with ESMTP id nBA0F4C1014318; Wed, 9 Dec 2009 18:15:05 -0600
Received: from [] ( by ( with Microsoft SMTP Server id 8.1.375.2; Wed, 9 Dec 2009 19:14:39 -0500
Message-ID: <>
Date: Wed, 9 Dec 2009 19:13:25 -0500
From: Suresh Krishnan <>
User-Agent: Thunderbird (X11/20090817)
MIME-Version: 1.0
To: Jari Arkko <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
Cc: DNA <>, "" <>, "" <>, IESG <>, Lars Eggert <>
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: Thu, 10 Dec 2009 00:15:11 -0000

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.