Re: [Gen-art] Gen-art LC review of draft-ietf-manet-rfc6779bis-05

"Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com> Fri, 06 May 2016 14:13 UTC

Return-Path: <chris.dearlove@baesystems.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299AE12D545; Fri, 6 May 2016 07:13:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.905
X-Spam-Level:
X-Spam-Status: No, score=-7.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
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 C1nqHHi0fOdN; Fri, 6 May 2016 07:13:53 -0700 (PDT)
Received: from ukmta2.baesystems.com (ukmta2.baesystems.com [20.133.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ABBA12D1D0; Fri, 6 May 2016 07:13:52 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.24,585,1454976000"; d="scan'208,217"; a="34851224"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 06 May 2016 15:13:51 +0100
X-IronPort-AV: E=Sophos;i="5.24,585,1454976000"; d="scan'208,217";a="117035626"
Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds016.greenlnk.net with ESMTP; 06 May 2016 15:13:51 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.5.88]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0248.002; Fri, 6 May 2016 15:13:50 +0100
From: "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com>
To: Elwyn Davies <elwynd@dial.pipex.com>, General area reviewing team <gen-art@ietf.org>
Thread-Topic: Gen-art LC review of draft-ietf-manet-rfc6779bis-05
Thread-Index: AQHRp5t4bD/NcCrHWkKWePrjfYd3yp+r7qhQ
Date: Fri, 06 May 2016 14:13:49 +0000
Message-ID: <B31EEDDDB8ED7E4A93FDF12A4EECD30D923B373A@GLKXM0002V.GREENLNK.net>
References: <572C9C6D.9080509@dial.pipex.com>
In-Reply-To: <572C9C6D.9080509@dial.pipex.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.109.62.6]
Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B373AGLKXM0002VGREEN_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/CRYnFmk5iGYMVgL0wI7mUrdg_yo>
Cc: "draft-ietf-manet-rfc6779bis.all@ietf.org" <draft-ietf-manet-rfc6779bis.all@ietf.org>
Subject: Re: [Gen-art] Gen-art LC review of draft-ietf-manet-rfc6779bis-05
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 May 2016 14:13:56 -0000

Jumping in wearing document shepherd hat.

draft-ietf-manet-olsrv2-management-snapshot, which got as far as -03, was produced (I wasn’t an author). This described how, it said (I’m not doubting that, just trying to be precise) management is currently usually done for OLSRv2 and NHDP. Having just re-read it, I think it went a bit further into possibilities than just the snapshot of the title, which I’d advise removing.

I think it actually completed WGLC (I’d need to check that) but then the then AD (I think, might have been the chairs) killed it on the grounds that what was wanted was a document about management of MANETs in general. At this point I think the authors decided they’d done what they promised to do, and may have felt that the rules had been changed on them. I believe the authors have recently considered resurrecting it as an independent submission, but that hasn’t happened (yet).

As a document about OLSRv2/NHDP, it doesn’t actually fully satisfy the quote below. On the other hand both this document and it were covering the same ground (just OLSRv2 and NHDP - though it may be noted these are actually the only Standards Track MANET routing protocols) and the management document referenced the MIB documents.

So, the phrase as given below isn’t accurate, at least the word “will” isn’t. Limited to OLSRv2/NHDP it might be accurate as a possibility if independent submission or some other means to reopen the existing draft happened.

In addition, the MANET WG may recharter. It may add management as a topic. It then may produce the generic document that the existing document was killed for. Or may not.

I’d suggest that the most accurate thing to say at this point would be to simply delete this comment in this document.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: chris.dearlove@baesystems.com<mailto:chris.dearlove@baesystems.com>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://www.baesystems.com/ai>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

From: Elwyn Davies [mailto:elwynd@dial.pipex.com]
Sent: 06 May 2016 14:30
To: General area reviewing team
Cc: draft-ietf-manet-rfc6779bis.all@ietf.org
Subject: Gen-art LC review of draft-ietf-manet-rfc6779bis-05


*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-manet-rfc6779bis-05.txt
Reviewer: Elwyn Davies
Review Date: 2016/05/06
IETF LC End Date: 2016/05/16
IESG Telechat date: (if known) -

Summary: Ready with a couple of editorial nits.

Major issues: None

Minor issues: None

Nits/editorial comments:

The suggestions for the Abstract, s1 and s1.1 are intended to clarify the relationship to RFC 7466 in the introductory text (the later comments in the MIB itself are more than adequately clear about this!)
Abstract:
OLD:
   In particular, it
   describes objects for configuring parameters of the Neighborhood
   Discovery Protocol (NHDP) process on a router.
NEW:
   In particular, it
   describes objects for configuring parameters of the Neighborhood
   Discovery Protocol (NHDP) process on a router.  The extensions
   described in this document adds objects and values to support the
   NHDP optimisation described in RFC 7466.
END

s1:
OLD:
   In particular, it describes objects for configuring
   parameters of the Mobile Ad Hoc Network (MANET) Neighborhood
   Discovery Protocol (NHDP) [RFC6130] process on a router.
NEW:
   In particular, it describes objects for configuring
   parameters of the Mobile Ad Hoc Network (MANET) Neighborhood
   Discovery Protocol (NHDP) [RFC6130] process on a router.  The extensions
   described in this document adds objects and values to support the
   NHDP optimisation described in [RFC7466].
END
s1.1:
It might be worth adding a list of the changes since it is short and they are a bit buried:
I think they are:
 - Addition of objects nhdpIib2HopSetN2Lost and nhdpIfPerfCounterDiscontinuityTime.
 - Addition of extra value (notConsidered) to nhdp2HopNbrState.
 - Revised full compliance state.

s4:  We don't normally leave IPR statements in finished documents - Probably best to leave a RFC Editor instruction to delete the section before publication.

s7.3, para 2: The referent of 'this table' is not totally clear:
s/this table/the nhdpInterfaceTable/

s8, top of page 13 - DESCRIPTION below CONTACT INFO, last para:
OLD:
            This version of this MIB module is part of RFC 6779; see
            the RFC itself for full legal notices."
NEW:
            This version of this MIB module is part of RFC xxxx; see
            the RFC itself for full legal notices."

s10, para 1:  There are weasel words here:

A fuller discussion of MANET network

   management use cases and challenges will be provided elsewhere.
Has this now happened?  If so a reference would be desirable.  Otherwise maybe
   A full discussion of MANET network
   management use cases and challenges is beyond the scope of this document..


********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************