Subject: [pim] AD Review of draft-ietf-pim-mib-v2-06.txt

From: Bill Fenner <[email-masked]>
Date: Thu, 12 Oct 2006 16:46:34 -0700

I found 5 items of note:
1. StorageType or other spec for tables with creatable rows (RFC4181
section 4.6.4)
2. Similar question for regular objects that are writable.  I'm not
actually sure if this is in the review     requirements, but it is a
question - what happens if I change pimRegisterSuppressionTime, does it
get wrtten   to the config?
3. Several objects could use REFERENCE tags.  The ones I noticed:
  - pimInterfaceGenerationIDValue -> 4.3.1
  - pimInterfaceDRPriority -> 4.3.2
  - pimInterfaceLanDelayEnabled, EffectPropagDelay, EffectOverrideIvl, SuppressionEnabled -> 4.3.3
  - pimInterfaceBidirCapable -> bidir spec, somewhere
  - pimInterfaceDRPriorityEnabled -> 4.3.2
  - pimNeighborLanPruneDelayPresent, PropagationDelay, OverrideInterval, TBit -> 4.3.3
  - pimNeighborGenerationIDPresent -> 4.3.1
  - pimNeighborGenerationIDValue -> 4.3.1
  - pimNeighborBidirCapable -> bidir spec, somewhere
  - pimNeighborDRPriority* -> 4.3.2
  I stopped looking after the interface and neighbor tables.
4. Compliance statements.  It's all well and good to say that all the
groups are optional, but there is actually a syntax for saying "in this
condition, these groups are mandatory."  I think you actually want 4
(perhaps more, uhoh) compliance statements:
  - ASM (making pimSsmGroup, pimRPConfigGroup, pimSmGroup required)
  - Bidir (making pimRPConfigGroup, pimSmGroup, pimBidirGroup required)
  - SSM (making pimSsmGroup required)
  - DM (not sure off the top of my head which groups to require here)
The reason I say "perhaps more" is because there could be read-only
versions of these compliances too, for implementations that don't permit
PIM to be enabled/disabled per-interface or writing of the writable
objects (such an implementation wouldn't be compliant with any of the
compliances if they didn't subset the writable objects to say that
read-only was OK).
5. Order.  e.g., the pimInterfaceStatus is in the middle of the row,
while by convention it is at the end.  The pimInterfaceDRPriorityEnabled
object is far from the pimInterfaceDRPriority object.  Does it make sense
to try to reorder these objects so that related objects are close, etc?

I'm going to pass these issues along to the MIB Dr.s as ones that I've
already called out, and perhaps they can get worked on in parallel with
the further review that the MIB Dr.s will do.

Thanks,
  Bill

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim