[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: MIB Doctor review of: draft-ietf-mpls-ftn-mib-07.txt
OK, why don't you go ahaead and pubish
Thanks,
Bert
> -----Original Message-----
> From: Cheenu Srinivasan [mailto:cheenu_srinivasan@hotmail.com]
> Sent: woensdag 6 augustus 2003 14:55
> To: bwijnen@lucent.com
> Cc: dperkins@dsperkins.com; tnadeau@cisco.com;
> arunv@force10networks.com; zinin@psg.com; swallow@cisco.com;
> loa.andersson@utfors.se; mreview@ops.ietf.org
> Subject: RE: MIB Doctor review of: draft-ietf-mpls-ftn-mib-07.txt
>
>
> >End of section 5.2.2 says:
> >
> > The use of this indexing structure is further
> illustrated using an
> > example in Section 6.
> >
> >Probably better to say "example in Sections 6 and 7." ??
>
> That's a cross reference that word failed to update for
> whatever reason!
> Fixed to say "Section 7" (the one with the examples) now.
>
> http://www.geocities.com/cheenu_s/draft-ietf-mpls-ftn-mib-08.txt
>
> >You have:
> > mplsFTNMapRowStatus OBJECT-TYPE
> > SYNTAX RowStatus {
> > active(1),
> > createAndGo(4),
> > destroy(6)
> > }
> > MAX-ACCESS read-create
> > STATUS current
> >
> >Maybe we were not clear. But the way to do this is to not sub-type
> >the RowStatus in the OBJECT-TYPE definition, but instead to do so
> >in the MODULE-COMPLIANCE... or so I think... but thinking again what
> >we want to achieve (namely that one can never get into a notInservice
> >or notReady state), maybe it is correct here.
>
> I think we want to unconditionally restrict this RowStatus
> object to these
> 3 values so that we don't have issues with people creating
> other RowStatus
> values and then wondering what to do about the reindexing.
>
> Thanks,
> Cheenu
>
> _________________________________________________________________
> Tired of spam? Get advanced junk mail protection with MSN 8.
> http://join.msn.com/?page=features/junkmail
>