RE: AD review: draft-ietf-bridge-rstpmib-06.txt

A couple of observations:
=20

> -----Original Message-----
> From: David B Harrington [mailto:[email protected]]=20
> Sent: Wednesday, June 15, 2005 5:51 PM
> To: 'Wijnen, Bert (Bert)'; Romascanu, Dan (Dan); 'David Levi'
> Cc: 'Bridge-Mib (E-mail)'; 'David Kessens'
> Subject: RE: AD review: draft-ietf-bridge-rstpmib-06.txt=20
>=20
> Hi Bert,
>=20
> My responses to your comments are inline.
>=20
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:[email protected]]

....
> >=20
> > - I wonder how we control that assignments under dot1dStp will not=20
> > cause
> >   conflicts. This MIB module starts to asiign at { dot1dStp
> > 16 } which is the
> >   next available number according to RFC1493. But how will we keep=20
> > track?
>=20
> Would you like them registered with IANA, including a note=20
> that all subsequent dot1dStp values are reserved?
> As we transition to IEEE updates, will they be allowed to=20
> extend dot1dStp or do they need to use a different ieee8021=20
> subtree registration? Would that be problematic?

I believe that we should also talk with IEEE 802.1 to check with them
what are their preferences. They may not want or their rules may not
allow using an out-of-IEEE root for future work that is theirs.

>=20
> >=20
> > - I see not text that indicates the persistency behaviour of the=20
> > read-write
> >   objects.
>=20
> The IEEE standard does not discuss the persistency of the=20
> management variables. As long as the IEEE standard remains=20
> silent on this point, I think the corresponding IETF standard=20
> should also remain silent.=20
>=20
> The IEEE standard should be updated to discuss persistency of=20
> each management variable. The coresponding MIB objects should=20
> be updated to correspond, following SMI rules, as part of the=20
> IEEE standard update.

I believe that we should make a clarification request to the IEEE on
this, pointing specifically to the objects that need to have persistency
defined. If I understand well the implication of 'remaining silent' is
that no persistency is required from an agent implementer. This may have
backwards compatibility issues if the need for persistence is identified
in the future.=20

>=20
> Is there a way to clarify the persistence requirement for=20
> each object in the IETF bridge mibs once the IEEE updates=20
> their compliance requirements that would not require=20
> obsoleting and redefining each MIB object?=20
>=20
> WG - any comments on how to approach this?

Dan