RE: [imss] FW: MIB Doctor review draft-ietf-imss-fc-fam-mib-01.tx

["Wijnen, Bert (Bert)" <[e-mail]>]

Inline

> -----Original Message-----
> From: Keith McCloghrie [mailto:[e-mail]]
> Sent: Monday, October 10, 2005 18:46
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [imss] FW: MIB Doctor review
> draft-ietf-imss-fc-fam-mib-01.tx
> 
> 
> I've put a new version at:
> 
>    ftp://ftpeng.cisco.com/ftp/kzm/draft-ietf-imss-fc-fam-mib-02.txt
> 
I'll try to take a look at it after I wake up (it is time to go to bed now)

> > Keith, I also did a quick check on rev 02 that you pointed to.
> > Here are some additional nits that I found, and that you might
> > as well tidy up while working on it:
> > 
> > - issues with citations/references:
> >   !! Missing Reference for citation: [RFC2741]
> >   P005 L031:    single SNMP agent having multiple AgentX 
>     [RFC2741] sub-agents, with
>  
> I have removed "[RFC2741]".
> 
Thanks

> >   !! Missing Reference for citation: [RFC2863]
> >   P004 L044:    extensions to the standard IF-MIB [RFC2863] 
> >   for Fibre Channel
> >   (you seem to be using [IF-MIB] and also [RFC2863]. I 
> >   prefer the latter)
>  
> I have changed "[RFC2863]" to "[IF-MIB]"
> 

Not my preference, but valid and OK

> > - I would change (2 times):
> >     REVISION    "200510070000Z"
> >     DESCRIPTION
> >            "Initial version of this MIB module."
> >   into:
> >     REVISION    "200510070000Z"
> >     DESCRIPTION
> >            "Initial version of this MIB module, published as RFCyyyy."
> >            -- RFC-Editor, pls fill in xxxx for RFCyyyy
>    
> How is the RFC Editor going to know what "xxxx" is ??   I 
> have changed it to :
> 
>   -- RFC Editor: replace yyyy with actual RFC number & remove 
> this note
> 

;-) 

> > - For consistency, I think I would change 
> >      t11FabricAddrMgrMIB MODULE-IDENTITY
> >   into
> >      t11FamMIB MODULE-IDENTITY
> >   but as I said, it is a nit.
>  
> Thanks for catching this, but I believe that consistency 
> requires it to be:
> 
>   t11FcFabricAddrMgrMIB MODULE-IDENTITY
> 

Keith, I can live with it.
We named IF-MIB the ifMIB
We named SNMP-VIEW-BASED-ACM-MIB the snmpVacmMIB
We named SNMP-USER-BASED-SM-MIB the snmpUsmMIB
So... I won't block on this.

> > - indentation for various MIB objects and descriptions is 
> inconsistent
>  
> I've fixed those that I could find.
> 
> > Could you also comment on:
> > 
> >    W: f(t11fc.mi2), (699,13) Row "t11FamIfEntry" does not 
> have a consistent indexing
> >       scheme - cannot specify an index item from additional 
> "base row" fcmInstanceEntry,
> >       since can have only one "base row" which is ifEntry
> > 
> > I think it is OK, but would like to hear/read your comments.
>  
> Dave Perkins suggested (about seven or eight years ago) that this be
> included in RFC 2578, but the WG rejected it.  It is still in SMICng,
> but there a switch to ignore this "warning".  I forget which 
> switch it is.
> 
As I said, I think it is OK.
Just wanted to hear/understand you are aware of it and are doing it
consciously. I know the -Z switch in SMICng, so I can certainly 
suppress it and often do so. In fact I personally asked Perkins to add that
switch if I recall correctly (like I have asked several other switches)

> > Further, I have these somehwat more serious comments:
> > 
> > 1. I see in the t11FamTable a number of writable objects, but I seem to be
> >    missing any writeup as to what the expected persistency behaviour is
> >    for these objects. Am I not looking at the correct place?
> >    Same for t11FamIfTable. Maybe other places as well, pls check.
> 
> I have inserted into the MODULE-IDENTITY's DESCRIPTION
> 
>            After an agent reboot, the values of read-write objects
>            defined in this MIB module are implementation-dependent.
> 
> and near the end of each read-write object's DESCRIPTION:
> 
>            For the persistence of values across reboots, see the
>            MODULE-IDENTITY's DESCRIPTION clause."
> 

No my ideal. But as long as implementors can find what the expected behaviour
is (i.e. undefined or non-deterministic as you seem to say), then I am fine
with it. Implementors of applications will let the WG know if they are
happy with that or not.

> > 2. In that same table, I see Counter32 objects, but nothing about possible
> >    discontinuities and if any, which is the discontinuity timer.
> 
> RFC 2578 says:
>                                           ...  Discontinuities
>    in the monotonically increasing value normally occur at re-
>    initialization of the management system, and at other times as
>    specified in the description of an object-type using this ASN.1 type.
>    If such other times can occur, for example, the creation of an object
>    instance at times other than re-initialization, then a corresponding
>    object should be defined, with an appropriate SYNTAX clause, to
>    indicate the last discontinuity.
> 
> Note:  "... at other times as specified in the description 
> ...".  RFC 4181 does not alter this because it says:
> 
>      It is OK to use Counter32/64 for counters that may/will be reset
>      when the management subsystem is re-initialized or when other
>      unusual/irregular events occur ...    However, if it is
>      possible for such other unusual/irregular events to occur, the
>      DESCRIPTION clause MUST state that this is so and MUST describe
>      those other unusual/irregular events in sufficient detail that it
>      is possible for a management application to determine whether a
>      reset has occurred since the last time the counter was polled.  The
>      RECOMMENDED way to do this is to provide a discontinuity indicator
>      as described in RFC 2578 Sections 7.1.6 and 7.1.10.
> 
> Thus, the DESCRIPTION clause is required to mention discontinuities and have
> a discontinuity indicator *if* they can occur, not just at reboot, but at
> other times as well.
> 
> So, it is appropriate for you to ask the question, but my answer is:
> no, there are no discontinuities other than at reboot, and thus, the text
> I have is fine.
> 

And so all implementors have to wonder. Is the (in my view) missing text
not there on purpose or was it left out by accident. Adding the explanation
you provide here woudl make it clear for everyone, without trying to go
search all the details in several other documents.

> > 3. For t11FamIfRowStatus, I think you need to state if other writable column(s)
> >    can be changed or not when in active state.
>  
> The rule in RFC 4181 is broken -- it says:
> 
>        The DESCRIPTION clause of the status column MUST specify whether
>        or not it is possible to modify other columns in the same
>        conceptual row when the status value is active(1).  Note that in
>        many cases it will be possible to modify some writable columns
>        when the row is active but not others.  In such cases, the
>        DESCRIPTION clause for each writable column SHOULD state whether
>        or not that column can be modified when the row is active, and
>        the DESCRIPTION clause for the status column SHOULD state that
>        modifiability of other columns when the status value is active(1)
>        is specified in the DESCRIPTION clauses for those columns (rather
>        than listing the modifiable columns individually).
> 
> Note that the first sentence says what MUST be in the DESCRIPTION clause.
> The second and third sentences give an example of when the first sentence
> is *wrong*, and a SHOULD applies instead.
> 

That is a separate discussion and you could have commented on that when
we did IETF Last Call for that BCP document.

> Further, it is possible for any table, T, defined in any MIB module, that
> a future MIB module could define new read-write objects in a new table which
> AUGMENTS T.  Thus, the "In such cases" in third sentence above is a future
> possibility for all tables in all MIB modules.  So, *all* RowStatus objects:
> 
>        ... SHOULD state that modifiability of other columns when the status
>        value is active(1) is specified in the DESCRIPTION clauses for
>        those columns (rather than listing the modifiable columns
>        individually).
> 
> i.e., this is boilerplate, and effectively redundant.  Why do we require
> redundant text in DESCRIPTIONs ??
> 
> Furthermore, in this MIB, the MODULE-COMPLIANCE clause says that the
> MIN-ACCESS for both t11FamIfRcfReject and t11FamIfRowStatus is
> read-only, i.e., the implementation gets to choose whether write
> access is to be supported: a) at all times, b) at some times but not
> other times, or c) never.  Thus, the OBJECT-TYPE cannot require that
> writable columns be change-able/not change-able at any specific times.
> 

Well, that can be taken into account when you write the text, as it seems
you are doing below.

> In light of the above arguments, I propose to add:
> 
>            Implementations which support write-access to this object
>            can do so under whatever conditions they choose."
> 

In other words, and application developer has no idea if such an object
is writable or not and just has to use the trial and error method.
If the IPS community is happy with that, then so be it. I personally
do not suffer from such ambiguities. The IPS community who needs to 
develop management applications will suffer and experience less 
interoperability as a result.

WG, is that what you want?

> to the t11FamIfRcfReject's DESCRIPTION.
> 
> Keith.
> 

Bert

_______________________________________________
imss mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/imss