Subject: RE: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 30 Sep 2005 12:43:13 +0200

W.r.t.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, September 30, 2005 04:14
> To: Adrian Farrel; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt
> 

.. snip ..
> >
> > > Section 8. GMPLS Traffic Engineering MIB Module
> > > -----------------------------------------------
> > >
> > > smicngPRO gives the following:
> > >
> > > W: f(GMPLS-TE-STD-MIB), (1181,14) Item "gmplsTunnelErrorTLVs" should
> > > have SIZE specified
> >
> > Ack
> > Understood this to be optional, but planning to add size as 
> > per David's comments
> >
> > > W: f(GMPLS-TE-STD-MIB), (1362,13) For "gmplsTunnelDirection", syntax is
> > > identical
> > > W: f(GMPLS-TE-STD-MIB), (1371,13) For "gmplsTunnelPathComp", syntax is
> > > identical
> > > W: f(GMPLS-TE-STD-MIB), (1382,14) For "gmplsTunnelUpNotRecip", syntax is
> > > identical
> > > W: f(GMPLS-TE-STD-MIB), (1389,14) For "gmplsTunnelDownNotRecip", syntax
> > > is identical
> > > W: f(GMPLS-TE-STD-MIB), (1401,14) For "gmplsTunnelExtraParamsPtr", syntax
> > > is identical
> >
> > Nack
> > Meaningless warning message. Cannot fix without explanation.
> 
> 
> The object is defined as:
> 
> 
> gmplsTunnelDirection OBJECT-TYPE
>      SYNTAX  INTEGER {
>        forward (0),
>        bidirectional (1)
>      }
>      MAX-ACCESS read-create
>      STATUS  current
>      DESCRIPTION
>        "Whether this tunnel carries forward data only (is
>         unidirectional) or is bidirectional.
> 
>         Values of this object other than 'forward' are meaningful
>         only if gmplsTunnelLSPEncoding is not set to
>         'tunnelLspNotGmpls'."
>      DEFVAL { forward }
>    ::= { gmplsTunnelEntry 8 }
> 
> 
> The following (part of the ReadOnly compliance statement) is causing
> the warning because the SYNTAX defined in the object and the
> SYNTAX below are the same.  (Following the OBJECT are a
> few alternatives.)
> 
>   OBJECT gmplsTunnelDirection
>      SYNTAX INTEGER {
>        forward (0),
>        bidirectional (1)
>      }
>      MIN-ACCESS  read-only
>      DESCRIPTION
>        "Only forward (0) is required."
> 
> 
> If you do intend for the SYNTAX in both the OBJECT-TYPE and
> the OBJECT to be the same, then removing it from the OBJECT
> would get rid of the warning.  This is not a blocking issue, but
> it is duplicate info that does not need to be duplicated.
> So here is what the OBJECT statement would like:
> 
>   OBJECT gmplsTunnelDirection
>      MIN-ACCESS  read-only
>      DESCRIPTION
>        "Only forward (0) is required."
> 
> Another alternative would be to specify forward(0) only since
> this is what the DESCRIPTION is specifying, however, it is
> likely that you are probably allowing both, so I don't think this
> is what you intend, but this would also solve the compiler warning:
> 
>   OBJECT gmplsTunnelDirection
>      SYNTAX INTEGER {
>        forward (0),
>      }
>      MIN-ACCESS  read-only
>      DESCRIPTION
>        "Only forward (0) is required."
> 
> 
This last one is (in my view) the only correct one.
The SYNTAX in fact is inline with what is in the DESCRIPTION clause.
And that is in my view IMPORTANT.

Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 30 Sep 2005 12:43:13 +0200

W.r.t.
> > > 19) gmplsTunnelHopExpRvrsLabel and gmplsTunnelHopExpReverseLabelPtr
> > >
> > > Please change Rvrs to Reverse.
> >
> > Nack
> > Please see point 21 about name lengths
> 
> In other objects in this MIB module are named using the entire
> word Reverse ( e.g.
> GmplsTunnelReversePerfEntry ::= SEQUENCE {
>      gmplsTunnelReversePerfPackets     Counter32,
>      gmplsTunnelReversePerfHCPackets   Counter64,
>      gmplsTunnelReversePerfErrors      Counter32,
>      gmplsTunnelReversePerfBytes       Counter32,
>      gmplsTunnelReversePerfHCBytes     Counter64
>    })
> 
> So please either change these to all use Rvrs or instead of Rvrs use
> the entire word, Reverse.   Similarly with the use of Fwd and Forward,
> if you decide to use Reverse, then please use the entire word, Forward.
> If you decide to use Rvrs, then please use Fwd.    I prefer the words
> spelled out but just please be consistent.
> 

I have explained repeatedly (and it has been in the MIB review guidelines
(now RFC4181) for a long time), the 32 char limit is relaxed. 

And in general, consistency is MUCH more important (I think) than
limiting to 32 chars.

Bert