RE: MIB Doctor review of: draft-ietf-mpls-ftn-mib-07.txt

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

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." ??

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.

Dave ?? Otehr MIB Doctors?

Thanks,
Bert 

> -----Original Message-----
> From: Cheenu Srinivasan [mailto:cheenu_srinivasan@hotmail.com]
> Sent: woensdag 6 augustus 2003 3:04
> 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
> 
> 
> I have made modifications based on the latest round of comments
> from David and Bert.
> 
> http://www.geocities.com/cheenu_s/draft-ietf-mpls-ftn-mib-08.txt
> 
> Here are the latest changes:
> 
> - I've added section 6 which explains how the last chenged objects
>   can be used to avoid retrieval-modification interactions. I've
>   also added some text to these object descriptions themselves
>   to make this point.
> 
> - I've added a defval of nonVolatile for the storage type objects.
> 
> - mplsFTNMapRowStatus now has the following syntax:
>    SYNTAX              RowStatus {
>                              active(1),
>                              createAndGo(4),
>                              destroy(6)
>                           }
>   As David pointed out, doing this helped avoid a lot of unnecessary
>   explanations about the reindexing behavior associated with other
>   row status states.
> 
> If there are no further comments, I will post this version to the
> IETF site sometime tomorrow.
> 
> Thanks,
> Cheenu
> 
>