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 protected]<mailto:[email protected]>

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 protected]]
Sent: 06 May 2016 14:30
To: General area reviewing team
Cc: [email protected]
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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to