RE: [imss] Re: MIB doctor review for: T11-FC-SP-SA-MIB

["Bert Wijnen - IETF" <[e-mail]>]

Thanks for the answers Keith. Suggested changed look OK to me.

Bert Wijnen 

> -----Oorspronkelijk bericht-----
> Van: Keith McCloghrie [mailto:[e-mail]]
> Verzonden: woensdag 2 januari 2008 17:03
> Aan: Bert Wijnen - IETF
> CC: [e-mail]; Dan Romascanu; Keith McCloghrie; Black_David
> Onderwerp: [imss] Re: MIB doctor review for: T11-FC-SP-SA-MIB
> 
> 
> Bert,
>  
> > This is a review of the module as extracted from the
> > prelimenary draft-ietf-imss-fc-fcsp-mib-01.txt document
> > 
> > - I see:
> > 
> >    t11FcSpSaMIB  MODULE-IDENTITY
> >       LAST-UPDATED  "200702190000Z"
> >       ORGANIZATION  "T11"
> > 
> >    I think that IETF IMSS WG should be included as one of
> >    the ORGANIZATIONs that worked on this MIB module
>  
> Done.
> 
> > - Similar question w.r.t. discontinuity of timers as in my 
> >   earlier MIB reviews yesterday
>  
> See my response to the question (in my response to your comments on
> T11-FC-SP-AUTHENTICATION-MIB).
> 
> > - t11FcSpSaPropSecurityProt OBJECT-TYPE
> >     SYNTAX       INTEGER { espHeader(1), ctAuth(2) }
> > 
> >   I see this SYNTAX 3 times.
> >   Possibly candidate for a TC. Just a subjective thought.
>  
> OK, done.
>  
> > - FOr t11FcSpSaPropTSelListIndex and t11FcSpSaPropTransListIndex,
> >   I assume that a zero value means that there is no such list?
> >   Although from the DESCRIPTION clause of the t11FcSpSaPropRowStatus
> >   object I get the impression that a row with a zero value for
> >   either of these 2 objects cannot be made active. So maybe zero is
> >   not a valid value?
> 
> I've changed the first sentence of t11FcSpSaPropTSelListIndex's
> DESCRIPTION to say:
> 
>            "When the value of this objct is non-zero, it points to
>            the proposal's list of Traffic Selectors.  The value
>            must be non-zero in an active row of this table.
> 
> Similarly for to t11FcSpSaPropTransListIndex.
> 
> > - For t11FcSpSaTSelPropEntry I am a bit confused by:
> > 
> >            The StorageType of a row in this table is specified by
> >            the instance of t11FcSpSaIfStorageType which is INDEX-ed
> >            by the same values of fcmInstanceIndex, t11FcSpSaIfIndex
> >            and t11FcSpSaIfFabricIndex."
> >     INDEX  { fcmInstanceIndex, t11FcSpSaIfIndex,
> >              t11FcSpSaTSelPropListIndex, t11FcSpSaTSelPropIndex }
> > 
> >    The t11FcSpSaIfFabricIndex is not part of this INDEX clause, is it?
> >    So how can it be the same?
> > 
> > - Same question for t11FcSpSaTransEntry
>  
> Thanks for catching this - the intent of omitting the FabricIndex from
> the INDEX clause of t11FcSpSaTSelPropTable (and t11FcSpSaTransTable)
> was so that the same list of Traffic Selectors (or transforms) could be
> proposed for multiple SA's even when the SA's are on different Fabrics,
> which seemed like it would be useful in some situations.  However, the
> need to have a StorageType which is common for the lists and for the SA
> proposals, introduces an (always present) complication which I think
> outweighs the potential (and at most occasional) benefit.  That is, I no
> longer believe the omission is worthwhile.  If the WG agrees, I propose
> to change the rows in t11FcSpSaTSelPropTable and t11FcSpSaTransTable to
> be per-Fabric, i.e., to add t11FcSpSaIfFabricIndex into the INDEX
> clause of the t11FcSpSaTSelPropTable and of the t11FcSpSaTransTable.
> (Indeed, the DESCRIPTION of t11FcSpSaIfStorageType is already worded to
> assume this change will be made.)
> 
> > - I think that for t11FcSpSaPairTransListIndex and 
> t11FcSpSaPairTransIndex
> >   a vlue of zero is impossible (or makes no sense). If I am correct you
> >   may want to exclude that via a RANGE spec.
> 
> Done.
> 
> > - I have seen thos combination multipel times (in the set of 
> MIB modules)
> > 
> >    t11FcSpSaPairLifetimeLeft OBJECT-TYPE
> >       SYNTAX       Unsigned32
> >       MAX-ACCESS   read-only
> >       STATUS       current
> >       DESCRIPTION
> >            "The remaining lifetime of this SA pair, given in the
> >            units specified by the value of the corresponding
> >            instance of t11FcSpSaPairLifetimeLeft."
> >       ::= { t11FcSpSaPairEntry 6 }
> > 
> >    t11FcSpSaPairLifetimeLeftUnits OBJECT-TYPE
> >       SYNTAX       INTEGER {
> >                      seconds(1),      -- seconds
> >                      kiloBytes(2),    -- 10^^3 bytes
> >                      megaBytes(3),    -- 10^^6 bytes
> >                      gigaBytes(4),    -- 10^^9 bytes
> >                      teraBytes(5),    -- 10^^12 bytes
> >                      petaBytes(6),    -- 10^^15 bytes
> >                      exaBytes(7),     -- 10^^18 bytes
> >                      zettaBytes(8),   -- 10^^21 bytes
> >                      yottaBytes(9)    -- 10^^24 bytes
> >                    }
> > 
> > 
> >    Possibel candidates for a TC?
>  
> OK, done.
> 
> > - I have seen
> >     t11FcSpSaPairTerminate OBJECT-TYPE
> >        SYNTAX       INTEGER { noop(1), terminate(2) }
> > 
> >   That SYNTAX a few times. Candidate for a TC?
>   
> In this case, I think it's better to leave them as-is, because the two
> usages have different targets, and future additions to the enumerated
> values have the potential to apply in one usage but not in the other.
> 
> Thanks,
> Keith.
> 
> 
> _______________________________________________
> imss mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/imss
> 


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