Subject: Re: [manet] performance metrics directorate review of draft-ietf-manet-olsrv2-mib-06

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 1 May 2013 19:00:45 +0100

I didn't think it was out of place. However, I thought/hope no words
deletes should occur after WGLC only if discussed (your delete was not
discussed on list until my input). Do I have to review all versions updated
after WGLC? some people may not, they may think it will be discussed to
update I-Ds.

AB

On Tue, Apr 30, 2013 at 7:23 PM, Ulrich Herberg <[email-masked]> wrote:

> AB,
>
> this sentence was out-of-place in section 9 and not related to
> security considerations.
>
> Best regards
> Ulrich
>
> On Tue, Apr 30, 2013 at 10:58 AM, Abdussalam Baryun
> <[email-masked]> wrote:
> > Not sure in new version -07 why deleted some words/statement in section
> 9.
> >
> > AB
> >
> >
> >
> > On Mon, Apr 29, 2013 at 8:17 PM, Ulrich Herberg <[email-masked]>
> wrote:
> >>
> >> Adrian,
> >>
> >> yes, that was my intention...but sometimes, good intentions are not
> enough
> >> ;-)
> >>
> >> I have submitted a new revision with the one-word change that Benoit
> >> requested.
> >>
> >> Best regards
> >> Ulrich
> >>
> >> On Sun, Apr 28, 2013 at 10:31 AM, Adrian Farrel <[email-masked]>
> >> wrote:
> >> > Hi Ulrich,
> >> >
> >> > Did you intend to post a new revision to make this change?
> >> >
> >> > Thanks,
> >> > Adrian
> >> >
> >> >> -----Original Message-----
> >> >> From: Ulrich Herberg [mailto:[email-masked]]
> >> >> Sent: 15 April 2013 21:11
> >> >> To: Benoit Claise
> >> >> Cc: [email-masked]; Adrian Farrel;
> >> > [email-masked];
> >> >> [email-masked]
> >> >> Subject: Re: [manet] performance metrics directorate review of
> >> >> draft-ietf-
> >> >> manet-olsrv2-mib-06
> >> >>
> >> >> Benoit,
> >> >>
> >> >> thank you very much for this review. I agree that using the term
> >> >> "performance information" instead of "performance metrics" is a good
> >> >> idea. We will make the change.
> >> >>
> >> >> Best regards
> >> >> Ulrich
> >> >>
> >> >> On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise <[email-masked]>
> >> >> wrote:
> >> >> > Dear all,
> >> >> >
> >> >> > I reviewed
> http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06,
> >> >> > from a
> >> >> > performance metric directorate point of view.
> >> >> >
> >> >> > This draft doesn't contain any reference to RFC6390, but contains
> >> >> > "performance metric". Hence this review was triggered. For details
> >> >> > about the
> >> >> > directorate, see
> >> >> > http://www.ietf.org/iesg/directorate/performance-metrics.html
> >> >> >
> >> >> >
> >> >> > Definition of Managed Objects for the  Optimized Link State Routing
> >> >> > Protocol version 2
> >> >> >
> >> >> > Abstract
> >> >> >
> >> >> >    This document defines the Management Information Base (MIB)
> module
> >> >> >    for configuring and managing the Optimized Link State Routing
> >> >> >    protocol version 2 (OLSRv2).  The OLSRv2-MIB module is
> structured
> >> >> >    into state information, performance metrics, and notifications.
> >> >> > This
> >> >> >    additional state and performance information is useful to
> >> >> >    troubleshoot problems and performance issues of the routing
> >> >> > protocol.
> >> >> >    Different levels of compliance allow implementers to use smaller
> >> >> >    subsets of all defined objects, allowing for this MIB module to
> be
> >> >> >    deployed on more constrained routers.
> >> >> >
> >> >> >
> >> >> > Basically, all performance metrics come from this table:
> >> >> >
> >> >> >    o  olsrv2InterfacePerfTable - records performance counters for
> >> >> > each
> >> >> >       active OLSRv2 interface on this device. selected path to each
> >> >> >       destination for which any such path is known.  This table has
> >> >> >       AUGMENTS { nhdpInterfacePerfEntry } and as such it is indexed
> >> >> > via
> >> >> >       nhdpIfIndex from the NHDP-MIB.
> >> >> >
> >> >> > NHDP-MIB is RFC 6779:
> >> >> >    NhdpInterfacePerfEntry ::=
> >> >> >       SEQUENCE {
> >> >> >          nhdpIfHelloMessageXmits
> >> >> >             Counter32,
> >> >> >          nhdpIfHelloMessageRecvd
> >> >> >             Counter32,
> >> >> >          nhdpIfHelloMessageXmitAccumulatedSize
> >> >> >             Counter64,
> >> >> >          nhdpIfHelloMessageRecvdAccumulatedSize
> >> >> >             Counter64,
> >> >> >          nhdpIfHelloMessageTriggeredXmits
> >> >> >             Counter32,
> >> >> >          nhdpIfHelloMessagePeriodicXmits
> >> >> >             Counter32,
> >> >> >          nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount
> >> >> >             Counter32,
> >> >> >          nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount
> >> >> >             Counter32,
> >> >> >          nhdpIfHelloMessageXmitAccumulatedLostNeighborCount
> >> >> >             Counter32
> >> >> >       }
> >> >> >
> >> >> >
> >> >> > This draft contains similar objects in olsrv2InterfacePerfTable :
> >> >> >
> >> >> >     Olsrv2InterfacePerfEntry ::=
> >> >> >        SEQUENCE {
> >> >> >           olsrv2IfTcMessageXmits
> >> >> >              Counter32,
> >> >> >           olsrv2IfTcMessageRecvd
> >> >> >              Counter32,
> >> >> >           olsrv2IfTcMessageXmitAccumulatedSize
> >> >> >              Counter64,
> >> >> >           olsrv2IfTcMessageRecvdAccumulatedSize
> >> >> >              Counter64,
> >> >> >           olsrv2IfTcMessageTriggeredXmits
> >> >> >              Counter32,
> >> >> >           olsrv2IfTcMessagePeriodicXmits
> >> >> >              Counter32,
> >> >> >           olsrv2IfTcMessageForwardedXmits
> >> >> >              Counter32,
> >> >> >           olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount
> >> >> >              Counter32
> >> >> >        }
> >> >> >
> >> >> >
> >> >> > Personally, I don't believe that those objects should be subject to
> >> >> > the RFC
> >> >> > 6390 template definition. (Performance Metric Definition Template,
> >> >> > section
> >> >> > 5.4.4, RFC 6390).
> >> >> > First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779] was
> >> >> > not
> >> >> > subject to it
> >> >> > Second reason: these objects are not really performance metrics,
> but
> >> >> > mainly
> >> >> > basic monitoring objects.
> >> >> >
> >> >> > Since RFC 6779 uses the term performance information (in the
> >> >> > abstract), I
> >> >> > would propose that draft-ietf-manet-olsrv2-mib also uses this term,
> >> >> > and not
> >> >> > the "performance metric". That would avoid some confusion. However,
> >> >> keeping
> >> >> > the olsrv2InterfacePerfTable OID name is perfectly fine, for
> >> >> > consistency
> >> >> > reason with RFC 6779.
> >> >> >
> >> >> > Regards, Benoit
> >> >> >
> >> >> >
> >> >> >
> >> >> > _______________________________________________
> >> >> > manet mailing list
> >> >> > [email-masked]
> >> >> > https://www.ietf.org/mailman/listinfo/manet
> >> >> >
> >> >
> >> _______________________________________________
> >> manet mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/manet
> >
> >
> >
> > _______________________________________________
> > manet mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/manet
> >
>

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 2 May 2013 07:34:02 -0700

AB,

I let Adrian reply if he thinks the changes are significant enough to
warrant a new WGLC. I think this is not the case. The sentence was
probably a copy&paste mistake and does not provide any value in the
Security Considerations section.

Best regards
Ulrich

On Wed, May 1, 2013 at 11:00 AM, Abdussalam Baryun
<[email-masked]> wrote:
> I didn't think it was out of place. However, I thought/hope no words deletes
> should occur after WGLC only if discussed (your delete was not discussed on
> list until my input). Do I have to review all versions updated after WGLC?
> some people may not, they may think it will be discussed to update I-Ds.
>
> AB
>
>
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 3 May 2013 11:02:17 +0100

Hi Ulrich,

Section 9 is not titled security consideration, that is section 8. The
delete was in section 9. However, I agree to leave it to the AD or
manet co-chair decisions,

Best Regards
AB

On Thu, May 2, 2013 at 3:34 PM, Ulrich Herberg <[email-masked]> wrote:

> deletes
> >> >> On Sun, Apr 28, 2013 at 10:31 AM, Adrian Farrel <[email-masked]
> >
> >> >> wrote:
> >> >> > Hi Ulrich,
> >> >> >
> >> >> >> On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise <[email-masked]
> >
> >> >> >> wrote:
> >> >> >> > Dear all,
> >> >> >> >
> >> >> >> > I reviewed

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 3 May 2013 13:22:27 +0100

Hello,
 
How nice to be sending email to the MANET list again after such a long time away
:-)
 
AB is right that the text was removed from section 9 (Applicability Statement)
and not the Security Considerations section (section 8).
 
Ulrich is right that the text was out of place. 
 
The text in section 9 of -06 read:
   OLSRv2 is designed to allow routers to leverage information on
   discovered routers and generate unicast routing paths within the
   MANET.
 
While this is undoubtedly true, it has nothing to do with the applicability of
the MIB module defined in this document. That is the purpose of Section 9.
 
Section 4 provides a brief overview of OLSRv2 (obviously deferring to
draft-ietf-manet-olsrv2) and *that* is the correct place for a description of
the purpose/function of OLSRv2. Re-reading section 4 I find it already has
plenty of description of OLSRv2 without the need to explicitly include the text
deleted from section 9.
 
That is consistent with the review I did of the changes present in -07 before I
put the document on the IESG agenda. So I am comfortable with things going
forward as they are.
 
In general, document editors have latitude to make textual edits that do not
change the protocol specification in a document. At the extreme end of the
spectrum, you would not expect an editor to seek working group consensus (two
week poll of the WG called and judged by the chairs) on the placement of a comma
or fixing a spelling mistake. Thus, the removal of this sort of misplaced text
is easily within scope of what they can do without explaining themselves to the
WG.
 
Each new revision of a document is notified to the WG, and the diff files are
easily available. Indeed, the announcement notice includes a link to the diff.
Thus, those who are interested (and not everyone in the WG is interested in
every document) can easily check what has happened.
 
The pragmatic approach to document development is for the editors/authors to
lead, and for the WG to pull them back if they have concerns. usually, the
editors/authors will discuss the concerns that have been raised hoping to reach
agreement/compromise. If there is need, the editors will ask the chairs to call
consensus.
 
Thanks,
Adrian
 
From: Abdussalam Baryun [mailto:[email-masked]] 
Sent: 03 May 2013 11:02
To: Ulrich Herberg
Cc: adrian; [email-masked]; manet
Subject: Re: [manet] performance metrics directorate review of
draft-ietf-manet-olsrv2-mib-06
 
Hi Ulrich,
 
Section 9 is not titled security consideration, that is section 8. The delete
was in section 9. However, I agree to leave it to the AD or manet co-chair
decisions,
 
Best Regards
AB

Best regards
Ulrich

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 3 May 2013 07:18:52 -0700

Thank you for the clarification.

Best regards
Ulrich

On May 3, 2013, at 5:22 AM, Adrian Farrel <[email-masked]> wrote:

Hello,

How nice to be sending email to the MANET list again after such a long time
away :-)

AB is right that the text was removed from section 9 (Applicability
Statement) and not the Security Considerations section (section 8).

   MANET.

While this is undoubtedly true, it has nothing to do with the applicability
of the MIB module defined in this document. That is the purpose of Section
9.

Section 4 provides a brief overview of OLSRv2 (obviously deferring to
draft-ietf-manet-olsrv2) and *that* is the correct place for a description
of the purpose/function of OLSRv2. Re-reading section 4 I find it already
has plenty of description of OLSRv2 without the need to explicitly include
the text deleted from section 9.

That is consistent with the review I did of the changes present in -07
before I put the document on the IESG agenda. So I am comfortable with
things going forward as they are.

In general, document editors have latitude to make textual edits that do
not change the protocol specification in a document. At the extreme end of
the spectrum, you would not expect an editor to seek working group
consensus (two week poll of the WG called and judged by the chairs) on the
placement of a comma or fixing a spelling mistake. Thus, the removal of
this sort of misplaced text is easily within scope of what they can do
without explaining themselves to the WG.

Each new revision of a document is notified to the WG, and the diff files
are easily available. Indeed, the announcement notice includes a link to
the diff. Thus, those who are interested (and not everyone in the WG is
interested in every document) can easily check what has happened.

The pragmatic approach to document development is for the editors/authors
to lead, and for the WG to pull them back if they have concerns. usually,
the editors/authors will discuss the concerns that have been raised hoping
to reach agreement/compromise. If there is need, the editors will ask the
chairs to call consensus.

Thanks,

Adrian

*From:* Abdussalam Baryun
[mailto:[email-masked]<[email-masked]>]

*Sent:* 03 May 2013 11:02
*To:* Ulrich Herberg
*Cc:* adrian; [email-masked]; manet
*Subject:* Re: [manet] performance metrics directorate review of
draft-ietf-manet-olsrv2-mib-06

Hi Ulrich,

Best Regards

AB

AB,

Best regards
Ulrich

deletes