Re: [Fwd: Pls post this to forces WG list.]

[Robert Haas <[e-mail]>]

Bert, thanks for catching that last one! I fixed it in the updated
version:
http://www.ietf.org/internet-drafts/draft-ietf-forces-mib-10.txt
Regards,
-Robert

PS. My replies are posted on the forces list, and they include your notes.

"Bert Wijnen \(IETF\)" <[e-mail]> wrote on 09/09/2008 08:48:35
PM:

> [image removed]
>
> Re: [Fwd: Pls post this to forces WG list.]
>
> Bert Wijnen \(IETF\)
>
> to:
>
> Robert Haas
>
> 09/09/2008 08:52 PM
>
> Cc:
>
> "Romascanu, Dan \(Dan\)", forces
>
> I find the following errors in revision 9 of the document:
>
>   C:\bw\smicng\work>smicng forces.inc
>   E: f(forces.mi2), (77,11) Syntax error
>   E: f(forces.mi2), (396,1) Unrecognizable item in module - skipping to
end
>   W: f(forces.mi2), (8,31) "TimeStamp" imported but not used
>   W: f(forces.mi2), (15,11) "ZeroBasedCounter32" imported but not used
>
>   *** 2 errors and 2 warnings in parsing
>
> The first one is because you have this:
>
>       ForcesProtocolVersion ::= TEXTUAL-CONVENTION
>           STATUS      current
>           DESCRIPTION
>               "ForCES protocol version number.
>                The version numbers used are defined in the
>                specifications of the respective protocol:
>                1 - ForCESv1 [RFCzzzz]."
>  -- RFC Ed.: replace zzzz with actual RFC number of ForCES protocol
>  -- & remove this note
>           SYNTAX      Integer32 (1..255)
>           DISPLAY-HINT "d"
>
> The DISPLAY-HINT (I believe) has to be the listed before the STATUS
> clause. So This works:
>
>       ForcesProtocolVersion ::= TEXTUAL-CONVENTION
>           DISPLAY-HINT "d"
>           STATUS      current
>           DESCRIPTION
>               "ForCES protocol version number.
>                The version numbers used are defined in the
>                specifications of the respective protocol:
>                1 - ForCESv1 [RFCzzzz]."
>  -- RFC Ed.: replace zzzz with actual RFC number of ForCES protocol
>  -- & remove this note
>           SYNTAX      Integer32 (1..255)
>
> And in fact removes/fixes all other errors
>
> Here is SMICng explanation:
>
> E: f(forces.mi2), (77,40) Syntax of a TEXTUAL-CONVENTION definition is
>   <tcName> "::=" "TEXTUAL-CONVENTION"
>     <optDspHint>
>     <status>
>     <desc>
>     <optRefer>
>     <syntax>
>
> RFC2579 states it as well (page 2 and 3):
>
> TEXTUAL-CONVENTION MACRO ::=
>     TYPE NOTATION ::=
>                   DisplayPart
>                   "STATUS" Status
>                   "DESCRIPTION" Text
>                   ReferPart
>                   "SYNTAX" Syntax
>
> Other than that, your changes look fine to me.
>
> Bert
> p.s. do you forward my postings to the forces WG list?
> My postings do not get accepted.
>
> ----- Original Message -----
> From: "Robert Haas" <[e-mail]>
> To: "Bert Wijnen (IETF)" <[e-mail]>
> Cc: "Romascanu, Dan (Dan)" <[e-mail]>;
> Sent: Tuesday, September 09, 2008 2:52 PM
> Subject: Re: [Fwd: Pls post this to forces WG list.]
>
>
> > Thanks Bert, I made the changes as suggested, the updated draft is:
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-forces-mib-09.txt
> >
> > My summary of the changes is copied below (See Section 10 in the
draft).
> > Regards,
> > -Robert
> >
> > Changes from draft-ietf-forces-mib-08:
> >
> >   o  Changed the MIB objects forcesAssociationOtherMsgSent and
> >      forcesAssociationOtherMsgReceived to forcesAssociationOperMsgSent
> >      and forcesAssociationOperMsgReceived as they are not all other
> >      messages besides HB (comment from the General Area Review Team).
> >
> >   o  Changed MIB counter objects forcesAssociationHBMsgSent,
> >      forcesAssociationHBMsgReceived, forcesAssociationOperMsgSent, and
> >      forcesAssociationOperMsgReceived from Counter32 to
> >      ZeroBasedCounter32 (comment from Bert Wijnen).  Adapted the
> >      paragraph about statistics counters in section "Associations kept
> >      in the MIB"
> >
> >   o  Introduced a MIB object
forcesAssociationCounterDiscontinuityTime,
> >      and added it to the forcesAssociationEntry as well as to the
> >      forcesAssociationEntryDownStats notification and the
> >      forcesStatsGroup compliance group.  Added text on discontinuity
> >      for all counter objects.
> >
> >   o  Removed MIB counters from the forcesAssociationEntryUpStats
> >      notification, as passing now zero values is useless.
> >
> >
> >
> > "Bert Wijnen \(IETF\)" <[e-mail]> wrote on 09/08/2008
10:39:12
> > PM:
> >
> >> [image removed]
> >>
> >> Re: [Fwd: Pls post this to forces WG list.]
> >>
> >> Bert Wijnen \(IETF\)
> >>
> >> to:
> >>
> >> Robert Haas
> >>
> >> 09/08/2008 10:40 PM
> >>
> >> Cc:
> >>
> >> FORCES, "Romascanu, Dan \(Dan\)"
> >>
> >> From your description it sounds that indeed a ZeroBasedCounter32
would
> > be
> >> better. That way you indicate it starts at zero.
> >>
> >> And hearing that the same index (FEID+CEID) could come to life in the
> >> table after one has been deleted, that makes it as a discontinuity.
> >> How else would a NM appliation know that this is a different entry?
> >> And so a discontinuity timestamp is needed.
> >>
> >> If there are no other reason why a discontinuity can occur (I do not
> > know,
> >> because I know to little of forces), then it would be good to state
so.
> >>
> >> Text on page 32 of
> >>    > http://www.wtcs.org/snmp4tpc/FILES/Reference/snmp%20counters.pdf
> >> is an example of a discontinuity counter.
> >>
> >> Bert
> >> ----- Original Message -----
> >> From: "Robert Haas" <[e-mail]>
> >> To: <[e-mail]>
> >> Sent: Monday, September 08, 2008 7:44 PM
> >> Subject: Re: [Fwd: Pls post this to forces WG list.]
> >>
> >>
> >> > Bert,
> >> > Indeed, I refrained as I saw that the use of ZeroBasedCounter32 was
> > often
> >> > discouraged ... But in the ForCES MIB, when the ForCES association
> > comes
> >> > up, a table row is created, and when the association goes down, the
> > table
> >> > row is destroyed. So it would be more natural if the counters in
that
> > row
> >> > were zero-based (zeroed upon creation of the table row) instead of
> >> > starting at a random value. If you say it's an acceptable use case
> > then
> >> > I'll change to ZeroBasedCounter32.
> >> >
> >> > Note that an association is identified by its index which is the
> >> > concatenation of the FEID and CEID forming the association. So a
new
> >> > association coming up between the same FEID and CEID would appear
with
> > the
> >> > same index as a previous association that went down. Would this be
> >> > considered a discontinuity as the counters appear to be reset ?
Apart
> > from
> >> > that, what else would cause a discontinuity ?
> >> > I'd use the text from page 32 in
> >> > http://www.wtcs.org/snmp4tpc/FILES/Reference/snmp%20counters.pdf to
> >> > address this.
> >> >
> >> > Thanks,
> >> > -Robert
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > From:
> >> > Jamal Hadi Salim <[e-mail]>
> >> > To:
> >> > [e-mail]
> >> > Date:
> >> > 09/08/2008 03:07 PM
> >> > Subject:
> >> > [Fwd: Pls post this to forces WG list.]
> >> >
> >> >
> >> >
> >> > Bert,
> >> > Forwarded to Robert and Forces list (sorry couldnt figure how to
let
> > the
> >> > allow you to post without subscribing you)
> >> >
> >> > cheers,
> >> > jamal
> >> >
> >> > ----- Message from "Bert Wijnen \(IETF\)" <[e-mail]> on
> > Mon, 8
> >> > Sep 2008 11:17:42 +0200 -----
> >> > To:
> >> > [e-mail], [e-mail]
> >> > Subject:
> >> > Pls post this to forces WG list.
> >> > I am not on the list and do not want to subscribe either. So my
> >> > posting got bounced. Pls forward or post it for me.
> >> >
> >> > So if people want to comment/respond, they should explicitly
> >> > copy me.
> >> >
> >> > Bert Wijnen
> >> > ----- Original Message -----
> >> > From: "Bert Wijnen (IETF)" <[e-mail]>
> >> > To: <[e-mail]>
> >> > Cc: <[e-mail]>
> >> > Sent: Monday, September 08, 2008 10:54 AM
> >> > Subject: Re: Last Call: draft-ietf-forces-mib (ForCES MIB) to
> >> > ProposedStandard
> >> >
> >> >
> >> >>I sort of wonder if the Counter32 is the proper datatype for some
> >> >> of the counters. They sound more like ZeroBasedCounter32 to me.
> >> >>
> >> >> Further I do not see any text regarding possible discontinuities.
> >> >>
> >> >> Bert Wijnen
> >> >>
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >
>
>