Re: WG Last Call:dratf-ietf-bridge-ext-v2-03.txt

Hi,

I have the following comments on this draft.  I have divided my
comments into introductory text, P-BRIDGE-MIB, and Q-BRIDGE-MIB.

Introductory text comments:

1. Throughout the document, references to 802.1D-1998 should be
    updated to refer to 802.1D-2004.

2. References to RFC 1493 should refer to the updated version
    in draft-ietf-bridge-bridgemib-smiv2-07.txt.

3. Separate references to 802.1t are unnecessary, as .1t is now
    included in D-2004.

4. Separate references to 802.1u and 802.1v are unnecessary, as
    they are included in 802.1Q-2003.  (Note, I realize we are
    just trying to ship what we have and let IEEE deal with
    maintaining this, but it does seem unwise to approve a document
    for the IETF standards track that references obsolete versions
    of an IEEE specification, or that references an RFC that we are
    about to obsolete.)

5. The RFC editor does not allow references in the Abstract.  (Again,
    I realize the goal is to just ship it, but the RFC Editor will not
    publish this as is.)

6. In Section 2, the following sentence:

    "IEEE 802.1Q defined port-based Virtual LANs where membership
    is determined by the bridge port on which data frames are
    received"

    should be updated for protocol VLANs.

7. Section 2.1 begins with "This MIB includes...".  This should
    be replaced with "This document includes" or "The MIB modules
    defined in this document include"

8. In the Historical note in 2.1, bullet 4 says "Limit the total
    of objects.", which should probably be "Limit the total number
    of objects."

9. I'm not sure what we should do with section 3.1.1, since
    802.1D-2004 no longer defines the managed objects that we refer
    to here.

10. Section 3.3, first paragraph seems like an archaic leftover from
     SMIv1.  Do we really need to define what a T-C is here?  End of
     second paragraph talks about PIB modules, which I thought were dead.

11. Section 3.4 and 3.4.1 refer to MIB-II and RFC 1213 for the system
     group.  Shouldn't we be referring to RFC 3418 for the system group?

12. In section 3.4.2.1, second paragraph, the recommendation that VLANs
     are not represented in the ifTable conflicts with SMON.  Not sure
     what to do about this one, and I'm not sure IEEE is the right place
     to deal with it.

13. Much of the text in section 3.4.3 is about to be rendered obsolete
     by draft-ietf-bridge-bridgemib-smiv2-07.txt.

P-BRIDGE-MIB comments:

1. There are several problems with the MODULE-IDENTITY:

    - LAST-UPDATED and REVISION dates need updating
    - Need to keep the original REVISION clause from 2674 and just add
      another revision for this version
    - DESCRIPTION needs the required copyright boilerplate
    - REVISION DESCRIPTION needs to identify changes made to this module
      since 2674 (one of Bert's favorite IESG Discusses...)
    - CONTACT-INFO normally has editor's contact info

2. REFERENCE clauses should point to currently published IEEE document,
    not to an old IEEE draft.

3. Several formatting oopses throughout See
    dot1dPortPriorityT
able
    for an example.  There were more spurious line feeds like this
    scattered throughout the document.

4. Description of dot1dPortOutboundAccessPriority seems wrong - outbound
    definition talks about received frame instead of transmitted frame.

5. pBridgePortGmrpGroup adds a new object to an existing group from
    2674, which is forbidden by the SMI.  We will need to deprecate
    the existing group and define a new group that includes the new
    object.  Note that this will also mean defining a new
    MODULE-COMPLIANCE that includes the new group.

Q-BRIDGE-MIB comments:

1. MODULE-IDENTITY has the same problems listed above.

2. VlanIdOrAny, VlanIdOrNone, VlanIdOrAnyOrNone: The statement in
    section 3.3 that says: "Notre that a MIB object that is defined
    using one of these textual conventions should clarify the meaning
    of 'any VLAN' and/or 'no VLAN' in its DESCRIPTION clause." should
    be included in the DESCRIPTION clauses of these T-Cs.

3. dot1qForwardAllStaticPorts description talks about non-EFS behaviour,
    but the acronym EFS has not been defined, and does not appear
    anywhere else in this document.

4. The description of dot1qPortAcceptableFrameTypes is no longer
    accurate with protocol VLANs.

5. There are several formatting glitches in this module, like in
    P-BRIDGE-MIB.  Note that these make the module uncompilable.

6. Again, qBridgePortGroup was modified from RFC 2674, which the
    SMI does not allow.

7. qBridgeCompliance was also modified to add the two new OBJECT-GROUPs
    which is also not allowed by the SMI.

8. 802.1Q says that support for management configuration of the
    protocol group database is optional.  An implementation that
    implements a fixed set of database entries is fully compliant.
    Therefore, the new MODULE-COMPLIANCE must allow
    dot1vProtocolGroupId and dot1vProtocolGroupRowStatus to be
    implemented read-only, otherwise we are taking something that is
    optional in 802.1Q and making it mandatory to comply with the
    MIB defintion.

Thanks,
John

David B Harrington wrote:
> Hi,
> 
> This starts the WG last call for the update to RFC2674. 
> We missed the IETF61 publication deadline, so the document can be
> found at:
>  
> http://www.ibr.cs.tu-bs.de/users/schoenw/draft-ietf-bridge-ext-v2-03.t
> xt
> 
> The WG last call will end November 23.
> This date has been chosen to ensure that 
> 	1) IETF61 attendees have two weeks to perform reviews, 
> 	2) attendees of the IEEE meeting the following week have two
> weeks to perform reviews,
> 	3) the ID publication lockout is lifted and the document
> becomes available in the normal repository
> If anybody has objection to this date, please post your concerns to
> [email protected].
> If anybody has comments on the draft, please post them to
> [email protected]
> 
> Thanks,
> David Harrington
> [email protected]
> Bridge-mib co-chair
>  
> 
> 
> 
> 
> _______________________________________________
> Bridge-mib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/bridge-mib
>