Re: Pls check and comment: draft-ietf-mboned-msdp-mib-01.txt (Experim ental)

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

Tables that don't support creation are a "standard" design
pattern. One of the first tables that supports only deletion,
but not creation is the TCP connection table.

I believe that we have talked about this topic many times,
and the approach that should be done is to have the
"RowStatus" object have a syntax clause that is
  SYNTAX     RowStatus { active(1), destroy(6) }

Thus, I believe that it is inappropriate that
the syntax of the "RowStatus" object be
  SYNTAX     RowStatus
and then have a MODULE-COMPLIANCE has shown
below.

On Tue, 21 Mar 2006, Wijnen, Bert (Bert) wrote:
> I am reviewing a Experimental draft
>    draft-ietf-mboned-msdp-mib-01.txt
> 
> I wonder if MIB doctors have comment on this doc and/or on
> my evaluation as per below.
> 
> Thanks,
> Bert
> 
> --------- draft evaluation by Bert:
> 
> I see:
> msdpSACacheEntry OBJECT-TYPE
>     SYNTAX     MsdpSACacheEntry
>     MAX-ACCESS not-accessible
>     STATUS     current
>     DESCRIPTION
>            "An entry (conceptual row) representing an MSDP SA
>             advertisement.  The INDEX to this table includes
>             msdpSACacheOriginRP for diagnosing incorrect MSDP
>             advertisements; normally a Group and Source pair would be
>             unique.
> 
>             Row creation is not permitted; msdpSACacheStatus may only be
>             used to delete rows from this table."
> 
> The way to express that last sentence is in the MODULE-COMPLIANCE
> with an entry aka:
> 
>         OBJECT     msdpSACacheStatus
>         SYNTAX     RowStatus { active(1), destroy(6) }
>         DESCRIPTION
>            "Row creation is not permitted; msdpSACacheStatus may only be
>             used to delete rows from this table."
> 
> I guess this can be done by a Note To RFC-Editor.
> 
> I wonder, do you want to keep the module name as DRAFT-MSDP-MIB
> 
> 
> I think for Experimental this is doc is acceptable. 
> For stads track or for registration under the mib-2 OID branch, 
> I would probably want various changes to this MIB module.
> I understand it also represents a MIB module that has been implemented
> and is being deployed in various environments.
> 
> Further,
> 
> Just for the record, and so that everyone knows.
> Below is a jabber conversation I had with Bill.
> 
> Bert
> ----------------
> 
> [08:57:10] *** fenner@jabber.psg.com is Online
> [08:57:19] <BertWijnen> Bill, I am looking at MSDP MIB.
> [08:58:08] <BertWijnen> Why did you use IpAddress instead of InetAddressIPv4 ??
> [08:58:28] *** fenner@jabber.psg.com is Offline
> [09:06:12] *** fenner@jabber.psg.com is Online
> [09:06:15] <fenner@jabber.psg.com> Because MSDP was defined to be v4-only, it's mentioned in the overview:
> 
> This MIB module uses the IpAddress SYNTAX, making it only suitable for
> IPv4 systems.  Although the desired direction for MIBs is to use
> InetAddressType/InetAddress pairs to allow both IPv4 and IPv6 (and
> future formats as well), the MSDP protocol itself is IPv4-only, and the
> MSDP working group made an explicit decision to not create an IPv6
> version of the protocol.
> 
> [09:06:58] <BertWijnen> But there is a separate InetAddressIPv4 TC (so not th pair) in 4001
> [09:07:46] <fenner@jabber.psg.com> There were some -0x draft revisions that did use InetAddress but nobody implemented them, and some people did have implementations of the IpAddress one (which I first wrote in 1999 so I claim that not having used the InetAddress stuff was excusable) so we went for compatability with existing implementations
> [09:08:36] <BertWijnen> OK, now I understand.
> 
> 

Regards,
/david t. perkins