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

Hi Bert,

My latest comments to your latest comments inline.

dbh
 
> > > 
> > > - I wonder how we control that assignments under dot1dStp 
> > > will not 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 track?
> > 
> > Would you like them registered with IANA, including a note that
all
> > subsequent dot1dStp values are reserved?
> 
> Well, that is what we did for RMON, i.e. registrations under: rmon
> I think it migh tbe usefull to document them some place and
> keep a registry.  

I will craft some text for an IANA document. 
 
> > As we transition to IEEE updates, will they be allowed to extend
> > dot1dStp or do they need to use a different ieee8021 subtree
> > registration? Would that be problematic?
> > 
> 
> I think that we still need to decide on what to do with the OID
trees
> when we transfer to IEEE. If they do their documents, and make them
> publicly available and if we can check the MIB before it gets 
> published, then maybe we can keep the OIDs as they currently are and
> let IEEE do extensions. But it is clear that in that case we (IETF)
> would want to have sign-off authority before such OID branches
> get assigned by IANA. If we do that, then that maybe one more
> reason to write a doc similar to RFC3737 for an IANA conrolled
> and administered bridgemib OID registry. Not sure if that would be
> acceptable to IEEE 802. 

I am working on a transition document with Dan and the chairs of
802.1, and we will address this issue in that document.

> > > - I see not text that indicates the persistency behaviour of 
> > > the read-write
> > >   objects.
> > 
....
> 
> So I understand that clarifying text was added that now in fact
states
> that they MUST be retained across re-init, except for:
> 
>   dot1dStpPortProtocolMigration
> 
> Was that an oversight?

No that was a deliberate decision of the 802.1 WG.
Note that the compliance clauses also have some information about the
persistency.

David Harrington
[email protected]