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

[Elwyn Davies <[e-mail]>]

Hi.


On 06/05/16 15:13, Dearlove, Christopher (UK) wrote:
>
> 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.
>
> *-- *
>
I wouldn't have a problem with this 'solution'.
*
*Cheers,
Elwyn*
*
>
> **
>
> *Christopher Dearlove
> Senior Principal Engineer
> BAE Systems Applied Intelligence Laboratories
> **__________________________________________________________________________
> *
> *T*:  [phone]  | *E: *[e-mail] 
> <mailto:[e-mail]>
>
> 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:[e-mail]]
> *Sent:* 06 May 2016 14:30
> *To:* General area reviewing team
> *Cc:* [e-mail]
> *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.
> ********************************************************************
>