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

From: Keith McCloghrie <[email-masked]>
Date: Wed, 2 Jan 2008 08:03:10 -0800 (PST)

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/imss

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Thu, 3 Jan 2008 13:07:51 +0100

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

Bert Wijnen 

> -----Oorspronkelijk bericht-----
> Van: Keith McCloghrie [mailto:[email-masked]]
> Verzonden: woensdag 2 januari 2008 17:03
> Aan: Bert Wijnen - IETF
> CC: [email-masked]; Dan Romascanu; Keith McCloghrie; Black_David
> Onderwerp: [imss] Re: MIB doctor review for: T11-FC-SP-SA-MIB
> 
> 
> Bert,
>