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

From: Elwyn Davies <[email-masked]>
Date: Fri, 6 May 2016 14:30:21 +0100

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> 
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq%3E>.

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..

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 6 May 2016 14:13:49 +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: [email-masked]<mailto:[email-masked]>

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:[email-masked]]
Sent: 06 May 2016 14:30
To: General area reviewing team
Cc: [email-masked]
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>.

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

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.

   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.
********************************************************************

---

From: Elwyn Davies <[email-masked]>
Date: Fri, 6 May 2016 15:38:47 +0100

Hi.

On 06/05/16 15:13, Dearlove, Christopher (UK) wrote:
> 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.
>
> *-- *
>
I wouldn't have a problem with this 'solution'.
*
*Cheers,
Elwyn*
*
> **
> *Christopher Dearlove
> **__________________________________________________________________________
> *
> *T*:  +44 (0)1245 242194  | *E: [email-masked] 
> <mailto:[email-masked]>
>
> www.baesystems.com/ai <http://www.baesystems.com/ai>
>
> *From:*Elwyn Davies [mailto:[email-masked]]
> *Sent:* 06 May 2016 14:30
> *To:* General area reviewing team
> *Cc:* [email-masked]
> *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>.//
>
> 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>.
>