[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Pls check and comment: draft-ietf-mboned-msdp-mib-01.txt (Exp erim ental)
OK, so I got several of the same comments now. Seems I went
the wrong path. I will suggest them to use that SYNTAX for the
object itself.
Bert
-----------
Date: Tue, 21 Mar 2006 10:31:27 -0800 (PST)
From: "David T. Perkins" <dperkins@dsperkins.com>
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
cc: "Mreview (E-mail)" <mreview@ops.ietf.org>
Subject: Re: Pls check and comment: draft-ietf-mboned-msdp-mib-01.txt (Experim
ental)
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
>=20
> I wonder if MIB doctors have comment on this doc and/or on
> my evaluation as per below.
>=20
> Thanks,
> Bert
>=20
> --------- draft evaluation by Bert:
>=20
> 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.
>=20
> Row creation is not permitted; msdpSACacheStatus may only be
> used to delete rows from this table."
>=20
> The way to express that last sentence is in the MODULE-COMPLIANCE
> with an entry aka:
>=20
> 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."
>=20
> I guess this can be done by a Note To RFC-Editor.
>=20
> I wonder, do you want to keep the module name as DRAFT-MSDP-MIB
>=20
>=20
> I think for Experimental this is doc is acceptable.=20
> For stads track or for registration under the mib-2 OID branch,=20
> 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.
>=20
> Further,
>=20
> Just for the record, and so that everyone knows.
> Below is a jabber conversation I had with Bill.
>=20
> Bert
> ----------------
>=20
> [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 InetAddressI=
Pv4 ??
> [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:
>=20
> This MIB module uses the IpAddress SYNTAX, making it only suitable for
> IPv4 systems. =A0Although 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.
>=20
> [09:06:58] <BertWijnen> But there is a separate InetAddressIPv4 TC (so no=
t th pair) in 4001
> [09:07:46] <fenner@jabber.psg.com> There were some -0x draft revisions th=
at did use InetAddress but nobody implemented them, and some people did hav=
e implementations of the IpAddress one (which I first wrote in 1999 so I cl=
aim that not having used the InetAddress stuff was excusable) so we went fo=
r compatability with existing implementations
> [09:08:36] <BertWijnen> OK, now I understand.
>=20
>=20
Regards,
/david t. perkins