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

Suresh Krishnan <suresh.krishnan@ericsson.com> Thu, 10 December 2009 00:15 UTC

Return-Path: <suresh.krishnan@ericsson.com>
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 6EAA33A68DD; Wed, 9 Dec 2009 16:15:10 -0800 (PST)
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 9-ZKhCsZ3WiO; Wed, 9 Dec 2009 16:15:06 -0800 (PST)
Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 7CF9F3A684F; Wed, 9 Dec 2009 16:15:06 -0800 (PST)
Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id nBA0F4C1014318; Wed, 9 Dec 2009 18:15:05 -0600
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; Wed, 9 Dec 2009 19:14:39 -0500
Message-ID: <4B203D25.5090409@ericsson.com>
Date: Wed, 9 Dec 2009 19:13:25 -0500
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Jari Arkko <jari.arkko@piuha.net>
References: <4B0655CB.2040309@piuha.net>
In-Reply-To: <4B0655CB.2040309@piuha.net>
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>, "draft-ietf-dna-simple@tools.ietf.org" <draft-ietf-dna-simple@tools.ietf.org>, IESG <iesg@ietf.org>, Lars Eggert <lars.eggert@nokia.com>
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: 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.

Thanks
Suresh