[manet] AD Review of draft-ietf-manet-olsrv2-management-snapshot

"Alvaro Retana (aretana)" <aretana@cisco.com> Fri, 29 May 2015 17:20 UTC

Return-Path: <aretana@cisco.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83441ACE5C; Fri, 29 May 2015 10:20:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCoj6HGYbz6y; Fri, 29 May 2015 10:20:23 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84B9B1ACEA9; Fri, 29 May 2015 10:18:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14003; q=dns/txt; s=iport; t=1432919914; x=1434129514; h=from:to:cc:subject:date:message-id:mime-version; bh=DUeqrV08jXplGMmDxyooH9lzxUXfsrwz1Mb+jV1r79U=; b=jR8bYWqb2IArwoCBDEopZmgh3xZLXsG4OUxbRH5KCpJy13mxA3T6PD02 AS/mxohNFNecfViWTA6SX270yC28BTKT5LF9q9Y/4E25ozPw5+Gjdm3gR rkt0tpDb3tXnNY6030Jjftisk+Atmk0wU6lXhjKb2sX/hCoAojcO5EFlm w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D6AwAsnmhV/5FdJa1cgkVLVGS+IAmBXIV1gUk4FAEBAQEBAQGBCoQlBHkSAYEAJwQOiDIN1SUBAQEBAQEBAwEBAQEBAQEBFgSNEoMzBIQ0BYtVhHmCPIQ1hl2BKYNxijiHYCODeII1gQEBAQE
X-IronPort-AV: E=Sophos;i="5.13,518,1427760000"; d="scan'208,217";a="154614293"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 May 2015 17:18:33 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t4THIX4e000486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 May 2015 17:18:33 GMT
Received: from xmb-aln-x15.cisco.com ([169.254.9.46]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Fri, 29 May 2015 12:18:33 -0500
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "draft-ietf-manet-olsrv2-management-snapshot@tools.ietf.org" <draft-ietf-manet-olsrv2-management-snapshot@tools.ietf.org>
Thread-Topic: AD Review of draft-ietf-manet-olsrv2-management-snapshot
Thread-Index: AQHQmjN9xuUWupS1Uk2vmrED/50a4g==
Date: Fri, 29 May 2015 17:18:32 +0000
Message-ID: <D18E1798.B4444%aretana@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.117.15.4]
Content-Type: multipart/alternative; boundary="_000_D18E1798B4444aretanaciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/manet/OaVr1xz-VLQqloA5v7O1iCPsQQ8>
Cc: "chris.dearlove@baesystems.com" <chris.dearlove@baesystems.com>, "manet@ietf.org" <manet@ietf.org>, "manet-chairs@ietf.org" <manet-chairs@ietf.org>
Subject: [manet] AD Review of draft-ietf-manet-olsrv2-management-snapshot
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 May 2015 17:20:25 -0000

Hi!

I just finished reading this document.

To start, I have a couple of high-level questions, maybe related to the history:

  1.  The name is somewhat tentative ("snapshot”), so I’m wondering if there was a specific reason the WG wanted to make emphasis on a point in time.  [By the fact of publishing something it is already a snapshot at that time.]
  2.  The methodology presented is very open (almost sounding as “you can do this, but that and the other thing are also seen sometimes more or less often”).  I’m wondering (thinking out loud) what is the value of publishing this document if it represents more a narrative of potential options than a coherent look at how OLSRv2 networks are in fact managed (at least in the majority case, if that exists).  I know that the mobile nature of the networks contribute to the above, but the fact that the WG (according to the Shepherd’s writeup [https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-management-snapshot/shepherdwriteup/]) didn’t show a lot of enthusiasm after adoption contributes to me wondering.

Other than that, my other comments are minor or nits (see below).

Assuming that the WG is still in support of this document moving forward, I am going to start the IETF Last Call and ask the Ops Directorate for an earlier-than-ususal review.  You can take my comments as part of the Last Call comments and incorporate them before the IESG review/discussion.

Thanks!

Alvaro.



Minor:

  1.  Introduction. "The MANET routing protocol OLSRv2 [RFC7181], as well as its constituent parts NHDP [RFC6130], [RFC5497], [RFC5148], [RFC5444],  [RFC7182], [RFC7183], [RFC7187], [RFC7188] is designed to autonomously maintain routes across a dynamic network topology.”  Are all these references needed?  Some of these references already update rfc7181 or rfc6130, which I think make them superfluous at this point.  [Note that I’m not suggesting not to use the specific RFCs as references elsewhere in the document if needed, just that at this point it seems like overkill.  For example, 5148, 7188 and 7187 are only referenced here.]
  2.  Section 3.3 (Security Material)  You made a couple of good points here about some networks not using any security and about the used of different mechanisms for key distribution.  It would be good to see some of this discussion in the Security Considerations section as well.
  3.  Section 3.4. (The Value of C).  C needs to be configured; is there a recommended initial value to be used?  [If I’m missing something obvious about this, please point me in the right direction.]
  4.  Section 4.2.  (External Management)
     *   "In some deployments, the NMS communicates with individual routers by way of SNMP - and, more commonly, by way of "proprietary" simpler, less verbose and (often) less secure protocols, and over UDP.”   Not issuing a recommendation or judgement, but because this document is reflecting current practice, it would be a good idea to also mention the potential risk of using “less secure” protocols in the Security Considerations section.
     *   “Note that this does not constitute a recommendation, but rather an observation..”  While the rest of that paragraph is true, I don’t think it belongs in this document.  In fact, it would be a good seed for discussion around the rechartering of the WG.
  5.  Section 7 (This Document does not Constrain how to Manage and Monitor MANETs)  I think that this section would have a higher impact if made a sub-section of the Introduction as it somewhat sets the tone for the rest of the document.
  6.  References.  I think that rfc7181 should be Normative as an understanding of OLSRv2 is needed to comprehend the document itself.

Nits:

  1.  Abstract.  It is not too long, but it rambles a bit.  Something more concise should do, with the rest moved to the Introduction:
     *   NEW>
     *      This document describes how Optimized Link State Routing protocol version 2 (OLSRv2)
     *      Routed Mobile Ad Hoc Networks (MANETs) are typically managed in terms of
     *      pre-deployment, as well as rationale and means of monitoring and management of
     *      MANET routers, including the MANET Neighborhood Discovery Protocol (NHDP).
  2.  Section 5 (What and Why do we Manage and Monitor?).
     *   Please expand “TC”.
     *   “..by an NMS in each router”  I think you mean here “by internal management”, to be consistent.