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. ********************************************************************
- [Gen-art] Gen-art LC review of draft-ietf-manet-r… Elwyn Davies
- Re: [Gen-art] Gen-art LC review of draft-ietf-man… Dearlove, Christopher (UK)
- Re: [Gen-art] Gen-art LC review of draft-ietf-man… Elwyn Davies