[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: review of draft-ietf-ccamp-lsr-mib-08.txt



Hi Bert.

Thanks.
If 32 chars is no longer a limit, we should make the suggested change.
I agree that consistency and comprehensibility of names are important.

Wrt compliance statements etc. I will try to wrap my brain around this,
but will probably need to bounce the resulting work off you and Joan.

Cheers,
Adrian
----- Original Message ----- 
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>; <tnadeau@cisco.com>;
<ccamp@ops.ietf.org>; <jcucchiara@mindspring.com>
Sent: Sunday, September 25, 2005 10:13 PM
Subject: RE: review of draft-ietf-ccamp-lsr-mib-08.txt


> W.r.t.
> > >40)   gmplsLabelModuleROCompliance MODULE-COMPLIANCE
> > >
> > >Please change the name to: gmplsLabelModuleReadOnlyCompliance
> > >to be consistent with the other MPLS and GMPLS MIB modules.
> >
> > Nack
> > I thought we tried to keep names down to 32 characters. I recall this
> > conversation before. Not mandatory, but desirable.
> >
>
> The "rule" of less than 32 has long ago been relaxed.
> I personally feel it is more important to be consistent in naming than
> having less than 32 chars.
>
> See RFC4181 sect 4.2
>
> But I agree it is not a fatal flaw, so we won't block on it.
>
> > A choice between two desires?
> >
> > >41) The ReadOnly compliance for gmplsLabelRowStatus
> > >does NOT have a MIN-ACCESS of read-only.  Is this
> > >intentional?
> >
> > ???
> > Not sure about this.
> > I thought the present of a WRITE-SYNTAX made some difference.
> >
>
> If you have a MODULE-COMPLIANCE statement as you do:
>
>    gmplsLabelModuleROCompliance MODULE-COMPLIANCE
>      STATUS current
>      DESCRIPTION
>             "Compliance requirement for implementations that only
>              provide read-only support for GMPLS-LABEL-STD-MIB. Such
>              devices can then be monitored but cannot be configured
>              using this MIB modules."
>
> So both the descriptor and the DESCRIPTION state that this is for
> read-only support, then it feels VERY WEIRD to me (actually it
> feels BROKEN to me) to not have all RowStatus objects be listed
> with MIN-ACCESS read-only. And having a WRITE-SYNTAX feels
> similarly weird.
>
> > >42) Also, (related to the above)
> > >     OBJECT       gmplsLabelRowStatus
> > >     SYNTAX       RowStatus {
> > >       active(1),
> > >       notInService(2)
> > >     }
> > >
> > >     WRITE-SYNTAX RowStatus {
> > >       active(1),
> > >       notInService(2),
> > >       createAndGo(4),
> > >       destroy(6)
> > >     }
> > >     DESCRIPTION
> > >       "Support for notInService, createAndWait and notReady is not
> > >        required."
> > >
> > >The DESCRIPTION clause conflicts with the WRITE-SYNTAX.
> > >Please clarify the intentions for this ReadOnly compliance
> > >object.
> >
> > Ack
> > There is an error here.
> >
>
> See my comment above. I think it should be MIN-ACCESS read-only
> and SYNTAX { active }. I do not see any other status to make sense.
>
>
> > >Section 12.2 Informational References
> > >---------------------------------------
> > >
> > >43a) The title of this section should be
> > >Informative.
> >
> > Ack/Nack
> >
> > I am aware of the RFC Editor's preferences.
> > Unfortunately these references are only informative if you read an
> > understand them (and
> > even then not always :-), but they are informational even if you don't
> > read or
> > understand them.
> >
>
> I know that RFC-editor uses a tool that prefers "informative".
> But it is probably not mandatory.
>
>
> Bert
>
>